AD-A258  915 

iBimnii 

AFIT/GCS/ENG/92D-02 


A  MODEL  FOR  DETERMINING 
TASK  SET  SCHEDULABILITY 
IN  THE  PRESENCE  OF 
SYSTEM  EFFECTS 

THESIS 

Rusty  Olen  Baldwin 
Captain,  USAF 

AFIT/GCS/ENG/92D-02 


Approved  for  public  release;  distribution  unlimited 


93  1  04  160 


AFIT/GCS/ENG/92D-02 


A  MODEL  FOR  DETERMINING  TASK  SET  SCHEDULABILITY  IN  THE 
PRESENCE  OF  SYSTEM  EFFECTS 


THESIS 


Presented  to  the  Faculty  of  the  School  of  Engineering 
of  the  Air  Force  Institute  of  Technology 
Air  University 
In  Partial  Fulfillment  of  the 


Requirements  for  the  Degree  of 
Master  of  Science  (Computer  Engineering) 


Rusty  Olen  Baldwin,  B.S.E.E. 
Captain,  USAF 


December,  1992 


|  Accession  For 

HTIS  GRA&I 

5/ 

DTIC  TAB 

□ 

Unannounced 

□ 

Just lricat 1  on _ 

By - 

Distribution/ 

Availability  Codes 
Avail  and/or 
Special 


Dlst  | 


Approved  for  public  release;  distribution  unlimited 


IT 


Acknowledgements 


Research  does  not  occur  in  a  vacuum  (well,  physics  research  sometimes  does  I  suppose),  it 
requires  the  support  and  involvement  of  many  people.  Thanks  go  to  Donna  Morris,  Clive  Benjamin, 
and  Otheos  Jackson  of  Wright  Lab  for  providing  the  equipment  necessary  to  conduct  this  research. 

I  would  also  like  to  express  my  deep  respect  for  and  gratitude  to  Major  Paul  Bailor.  His  sup¬ 
port,  technical  expertise,  and  the  high  standards  of  excellence  he  required  provided  the  motivation 
and  encouragement  needed  for  an  effort  such  as  this  to  be  successful. 

To  my  wife  and  son,  Heather  and  ian,  I  would  like  to  thank  you,  especially,  for  putting  up 
with  my  long  nights  and  frequent  absences,  and  also  for  your  loving  encouragement.  Finally  to  the 
most  recent  member  of  the  family,  Nathan,  I  would  like  to  thank  you  for  delaying  your  arrival  long 
enough  to  allow  me  to  complete  this  thesis.  Now  let’s  get  Ian  and  go  play! 


Rusty  Olen  Baldwin 


Table  of  Contents 


Page 

Acknowledgements .  ii 

Table  of  Contents  .  iii 

List  of  Figures .  viii 

List  of  Tables .  x 

Abstract .  xii 

I.  Introduction .  1-1 

1.1  Background .  1-1 

1.2  Problem  and  Research  Objectives  .  1-2 

1.2.1  Research  Hypothesis .  1-4 

1.2.2  Scope .  1-4 

1.3  Approach .  1-4 

1.3.1  High  Order  Language .  1-5 

1.3.2  Target  Hardware .  1-6 

1.3.3  System  Tasks .  1-6 

1.3.4  Task  Set .  1-6 

1.4  Assumptions .  1-7 

1.5  Organization .  1-8 

II.  Review  of  Current  Literature .  2-1 

2.1  Organization .  2-1 

2.2  Scope .  2-1 

2.3  Overview  of  Common  Scheduling  Theories .  2-1 

2.3.1  Shortest-process-time  first .  2-2 


in 


Page 

2.3.2  Earliest-deadline  first  .  2-2 

2.3.3  Shortest-slack-time  first .  2-3 

2.3.4  Cyclic  executive  .  2-3 

2.3.5  Rate  Monotonic  .  2-4 

2.3.6  Extensions  to  RMA  .  2-5 

2.3.7  Task  Synchronization  .  2-6 

2.4  Performance  .  2-8 

2.4.1  Performance  measurement  of  an  Ada  compilation  system  .  .  2-8 

2.4.2  Task  set  performance  measurement .  2-10 

2.5  Summary  and  Conclusions  .  2-11 

III.  Methodology  .  3-1 

3.1  Introduction  .  3-1 

3.2  Research  Methodology .  3-1 

3.2.1  Identify  the  System  Tasks .  3-2 

3.2.2  Measure  the  System  Tasks  .  3-3 

3.2.3  Predict  the  effect  -  RATESIM .  3-4 

3.2.4  Run  the  task  set .  3-5 

3.3  Equipment .  3-7 

3.3.1  Target  system .  3-7 

3.3.2  Host  system .  3-7 

3.3.3  Compilation  System .  3-8 

3.4  Data .  3-8 

3.5  Data  Analysis .  3-10 

3.5.1  Clock  Update  Time .  3-10 

3.5.2  Context  Switch  Time  .  3-11 

3.5.3  Rendezvous  Time .  3-11 

3.5.4  DELAY  Expiration  Time .  3-11 

3.6  Summary .  3-12 


IV 


Page 

IV.  Model  Requirements,  Design,  and  Testing .  4-1 

4.1  Purpose  and  Objectives .  4-1 

4.2  Motivation .  4-1 

4.3  Model  Requirements .  4-3 

4.3.1  Input  Requirements .  4-3 

4.3.2  Functional  Requirements  .  4-4 

4.3.3  Output  Requirements .  4-4 

4.3.4  RATESIM  Specification .  4-6 

4.3.5  Environmental  Model .  4-6 

4.4  RATESIM  Design .  4-7 

4.4.1  RATESIM  Transaction  Diagram  and  Data  Flow  Model  .  .  .  4-9 

4.4.2  Flow  Charts  .  4-10 

4.5  Testing  .  4-16 

4.5.1  Test  Cases  .  4-17 

4.5.2  Event  History  Example .  4-17 

4.6  Summary .  4-20 

V.  RATESIM  Validation  .  5-1 

5.1  Delay  Model  .  5-1 

5.2  System  Clock  Update .  5-3 

5.3  Scheduling  Algorithm .  5-4 

5.3.1  Task  Priorities .  5-4 

5.3.2  Scheduling  Decisions .  5-5 

5.4  Context  Switch  and  Rendezvous .  5-5 

5.4.1  Context  Switch .  5-6 

5.4.2  Rendezvous .  5-7 

5.5  Test  Cases  .  5-7 

5.5.1  Task  Set  A .  5-9 


v 


Page 

5.5.2  Task  Set  B .  5-10 

5.5.3  Task  Set  C .  5-11 

5.6  Summary .  5-12 

VI.  Conclusions  and  Recommendations .  6-1 

6.1  Introduction  .  6-1 

6.2  Conclusions .  6-3 

6.3  Recommendations  for  Future  Research .  6-3 

6.3.1  Runtime  Environment  Simulators .  6-4 

Appendix  A.  Delay  Model .  A-l 

A.l  XD  Ada  Delay .  A-l 

A. 1.1  Overview .  A-l 

A.  1.2  Hardware  Timers .  A-l 

A.2  Delay  Model  .  A-l 

A. 2.1  Error  Sources .  A-2 

A.3  Sample  Calculations .  A-2 

A.3.1  DelayRequest  =  460.0/is .  A-2 

A.3.2  DelayRequest  =  10100.0/is .  A-2 

A. 4  Statistics  and  Model  Error  .  A-3 

A.5  Delay  Model  and  Observed  Delay  Graphs .  A-7 

A. 6  Raw  Data .  A-18 

Appendix  B.  System  Clock  Update  Analysis .  B-l 

B. l  Overview .  B-l 

B.2  Interrupt  Response  Time .  B-l 

B.3  Interrupt  Handler  .  B-3 

B.4  Clock  Update  Analysis .  B-5 

vi 


Page 

Appendix  C.  Hartstone/RATESIM  Validation  Data .  C-l 

C.l  Task  Set  A  -  Harmonic  .  C-l 

C.1.1  Hartstone  Results  -  Experiment  1  .  C-l 

C.l. 2  RATESIM  Results  -  Experiment  1 .  C-5 

C.1.3  Hartstone  Results  -  Experiment  2  .  C-15 

C.l. 4  RATESIM  Results  -  Experiment  2 .  C-18 

C.l. 5  Hartstone  Results  -  Experiment  3  .  C-28 

C.1.6  RATESIM  Results  -  Experiment  3 .  C-32 

C.2  Task  Set  B  -  Nonharmonic  .  C-42 

C.2.1  Hartstone  Results  -  Experiment  1  .  C-42 

C.2.2  RATESIM  Results  -  Experiment  1 .  C-46 

C.2.3  Hartstone  Results  -  Experiment  2  .  C-56 

C.2.4  RATESIM  Results  -  Experiment  2 .  C-60 

C.2.5  Hartstone  Results  -  Experiment  3  .  C-70 

C.2.6  RATESIM  Results  -  Experiment  3 .  C-74 

C.3  Task  Set  C  -  Synchronization .  C-84 

C.3.1  Hartstone  Results  -  Experiment  2  (Task  Set  1) .  C-84 

C.3.2  RATESIM  Results  -  Experiment  2  (Task  Set  1) .  C-87 

C.3.3  Hartstone  Results  -  Experiment  2  (Task  Set  2) .  C-97 

C.3.4  RATESIM  Results  -  Experiment  2  (Task  Set  2) .  C-101 

Appendix  D.  RATESIM  Source  Code .  D-l 

Appendix  E.  ACEC  Test  Results .  E-l 

Appendix  F.  RATESIM  User’s  Manual .  F-l 

Bibliography .  BIB-1 

Vita .  VITA-1 


vu 


List  of  Figures 


Figure  Page 

1.1.  Test  Bed  Block  Diagram  .  1-7 

2.1.  Cyclic  Executive  Schedule .  2-4 

3.1.  Overview  of  the  ACEC .  3-4 

3.2.  Test  Bed  Block  Diagram  .  3-8 

4.1.  RATESIM  Context  Diagram .  4-21 

4.2.  RATESIM  Entity  Relationships .  4-22 

4.3.  Transaction  Diagram .  4-23 

4.4.  Level  2  DFD .  4-24 

4.5.  Level  2  DFD .  4-24 

4.6.  Level  3  DFD .  4-25 

4.7.  Do  System  Task .  4-25 

4.8.  Do  User  Task .  4-26 

4.9.  Do  User  Task(cont) .  4-27 

4.10.  Execute  Task .  4-28 

5.1.  Delay  Optimization .  5-11 

5.2.  Delay  Penalties .  5-13 

6.1.  Recommendations  for  Future  Research  .  6-6 

A.l.  (Observed  Additional  Delay  -  Model  Additional  Delay)  vs.  Delay  Request  ....  A-5 

A.2.  Model  Additional  Delay  vs.  Observed  Additional  Delay  -  100/js  data  .  A-6 

A.3.  Delay  Model  -  Ins .  A-8 

A.4.  Observed  Delay  -  1  fis .  A-8 

A.5.  Observed/Model  Delay  -  1  ns .  A-9 

viii 


Figure  Page 

A.6.  Delay  Model  -  10/is .  A-9 

A. 7.  Observed  Delay  -  10/is  .  A-10 

A.8.  Observed/ Model  Delay  -  10/is  .  A-10 

A.9.  Delay  Model  -  100/is .  A-ll 

A.IO.Observed  Delay  -  100/js .  A-12 

A.  11. Observed/Model  Delay  -  100/js .  A-12 

A.  12. Delay  Model  -  1000/iS .  A-13 

A.13,Observed  Delay  -  1000/js .  A-13 

A.14.0bserved/Model  Delay  -  1000/is .  A- 14 

A.  15. Delay  Model  -  10000/is .  A- 14 

A. 16. Observed  Delay  -  10000/is .  A-15 

A. 17-Observed/Model  Delay  -  10000/iS  .  A-15 

A. 18. Model  Delay  -  All  Data .  A-16 

A.19.0bserved  Delay  -  All  Data .  A-17 


IX 


List  of  Tables 


Table  Page 

2.1.  Shortest-process-time  first  task  set .  2-2 

2.2.  Hartstone  Tests  .  2-11 

3.1.  Task  Set  A  -  Periodic/Harmonic .  3-6 

3.2.  Task  Set  B  -  Periodic/Non-Harmonic  .  3-6 

3.3.  Task  Set  Cl  -  Periodic/Harmonic/Synchronization .  3-6 

3.4.  Task  Set  C2  -  Periodic/Harmonic/Synchronization .  3-7 

3.5.  Research  Equipment  and  software .  3-7 

3.6.  Research  Data .  3-8 

3.7.  Data  Definitions .  3-9 

4.1.  RATESIM  Specification .  4-21 

4.2.  Test  Cases  -  User  Input .  4-21 

4.3.  Test  Cases  -  Data  Integrity .  4-22 

4.4.  Test  Cases  -  Stress  Tests  .  4-23 

4.5.  RATESIM  Events .  4-29 

5.1.  Hartstone  Experiments .  5-8 

5.2.  Test  Results  -  Task  Set  A  -  Periodic/Harmonic .  5-9 

5.3.  Test  Results  -  Task  Set  B  -  Periodic/Non-Harmonic .  5-13 

5.4.  Test  Results  -  Task  Set  Cl  -  Periodic/Harmonic/Synchronization .  5-14 

5.5.  Test  Results  -  Task  Set  C2  -  Periodic/Harmonic/Synchronization .  5-14 

A.l.  Descriptive  Statistics  -  Observed  Additional  Delay .  A-3 

A. 2.  Descriptive  Statistics  -  Model  Error .  A-4 

A.3.  1  n»  data .  A- 18 

A.4.  l(i8  data  (cont)  .  A-19 


x 


Table  Page 

A.5.  1  ns  data  (cont)  .  A-20 

A. 6.  10 ns  data .  A-21 

A. 7.  10/is  data  (cont) .  A-22 

A.8.  10 ns  data  (cont) .  A-23 

A.9.  100/iS  data .  A-24 

A.10.100/j«  data  (cont) .  A-25 

A.ll.lOO^s  data  (cont) .  A-26 

A.12.100/is  data  (cont) .  A-27 

A.13.100/i«  data  (cont) .  A-28 

A.H.lOO/xs  data  (cont) .  A-29 

A.15.100j«s  data  (cont) .  A-30 

A.16.100/is  data  (cont) .  A-31 

A.17.100/is  data  (cont) .  A-32 

A.18.100/i«  data  (cont) .  A-33 

A.19.100/is  data  (cont) .  A-34 

A.20.100/i«  data  (cont) .  A-35 

A.21. 100/is  data  (cont) .  A-36 

A.22.1000/i«  data  .  A-37 

A.23.1000/i«  data  (cont) .  A-38 

A.24.1000/i«  data  (cont) .  A-39 

A.25.1000/is  data  (cont) .  A-40 

A. 26. 10, 000 /i«  data  .  A-41 


xi 


AFIT/GCS/ENG/92D-02 


Abstract 

This  research  developed  a  parameterized  model  that  accounts  for  system  overhead  and  de¬ 
termines  when  an  Ada  runtime  environment  can  no  longer  successfully  execute  a  given  Ada  task 
set  and  still  meet  all  deadlines.  The  Ada  Compiler  Evaluation  Capability  benchmark  was  used  to 
characterize  an  actual  runtime  environment.  Using  that  data,  a  generic  model  of  a  preemptive,  rate 
monotonic  priority  based  runtime  system  was  developed  which  accounts  for  overhead  due  to  clock 
updates,  context  switching,  task  suspension,  and  synchronization.  Validation  was  based  on  the 
Hartstone  benchmark.  First,  the  benchmark  was  executed  using  the  actual  runtime  environment. 
Then,  those  results  were  compared  with  the  execution  of  the  benchmark  using  the  model.  In  all 
cases,  except  one,  the  model  predicted  the  point  where  the  task  set  would  fail.  A  runtime  system 
optimization  omitted  from  model  caused  the  single  failure.  Experiments  conducted  using  the  model 
allowed  the  demonstration  of  the  following  results.  System  overhead  can  be  modeled  within  the 
existing  framework  of  rate  monotonic  scheduling  theory.  Runtime  optimizations  can  be  extremely 
sensitive  to  phase  relationships  between  task  periods  and  workloads  and  can  render  a  schedulable 
task  set  unschedulable.  Requirements  of  the  task  set  and  the  performance  of  the  runtime  system 
must  be  considered  simultaneously. 
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A  MODEL  FOR  DETERMINING  TASK  SET  SCHEDULABILITY  IN  THE 
PRESENCE  OF  SYSTEM  EFFECTS 


I.  Introduction 


1.1  Background 

An  embedded  system  is  a  computer  system  whose  main  purpose  is  other  than  computational, 
and  in  many  cases,  it  is  used  to  react  to  stimuli  from  its  environment  “rapidly  enough”  to  control 
that  environment  (2).  Embedded  systems  can  range  from  a  single  microprocessor  to  a  network 
of  large  computers  and  are  found  in  a  wide  variety  of  areas.  Typical  applications  of  embedded 
systems  include  flight  control  systems  in  aircraft  and  missiles,  chemical  process  controllers,  control 
applications  in  nuclear  reactors,  data  acquisition  systems,  and  environmental  control  systems.  The 
key  phrase  in  the  above  definition  is  rapidly  enough.  In  the  context  of  this  research,  rapidly 
enough  means  real-time  -  more  specifically  hard  real-time.  In  a  hard  reed-time  embedded  system, 
if  the  system  does  not  react  rapidly  enough  and  it  misses  a  deadline,  a  catastrophic  failure  will 
occur.  A  catastrophic  failure  may  result  in  the  loss  of  life,  property,  irrecoverable  loss  of  data,  or 
a  combination  of  the  three.  Therefore,  the  programs  which  run  on  embedded  computer  systems 
must  not  only  be  functionally  correct,  they  must  be  temporally  correct  as  well. 

Given  that  the  timing  correctness  of  a  hard  real-time  system  is  vital,  how  should  the  pro¬ 
cessor^)  in  an  embedded  system  be  utilized  such  that  all  tasks  that  the  processor  must  execute 
will  execute  rapidly  enough  to  affect  the  environment?  The  area  of  research  that  investigates  this 
problem  is  known  as  scheduling  theory.  The  goal  of  any  scheduling  theory  is  to  determine  how  to 
schedule  a  set  of  tasks  with  deadlines  on  a  processor  or  processors  so  that  all  the  deadlines  are  met. 
This  has  been  widely  studied  on  a  theoretical  level.  Often,  however,  there  is  a  discrepancy  between 
what  the  scheduling  theory  predicts  and  what  is  actually  observed  when  the  embedded  system 
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is  built  (16:i).  The  processing  reserve  capacity  is  frequently  much  less  than  analysis  indicated  it 
should  have  been  and/or  task  deadlines  are  missed  when  analysis  indicated  they  would  be  met. 
One  cause  of  this  discrepancy  can  be  attributed  to  system  overhead  and  blocking  not  accounted 
for  by  the  scheduling  theory.  Some  examples  of  system  overhead  and  blocking  include  context 
switching  time,  task  rendezvous  (or  synchronization),  I/O  blocking  time,  shared  data  access,  and 
garbage  collection.  Not  accounting  for  these  types  of  system  overhead  within  the  scheduling  theory 
can  prove  to  be  enormously  expensive  to  correct  in  a  system  design.  These  types  of  discrepancies 
were  encountered  when  estimating  throughput  requirements  for  the  Navy  F/A-18A  and  A- 12  air¬ 
craft  programs  (16:33).  By  regulation,  the  Navy  required  a  50%  throughput  reserve.  Based  on  the 
estimation  techniques  used  by  the  system  designers,  the  Naval  Avionics  Center  (NAC)  determined 
that  the  actual  throughput  reserve  was  significantly  less  than  that.  The  Navy  noted  that  correct¬ 
ing  these  deficiencies  in  an  existing  design  "...  is  technically  challenging,  and  can  add  months  to  a 
schedule,  as  well  as  depleting  large  amounts  of  money  from  the  program  budget”  (16:33). 

In  contrast  to  overutilizing  a  processor’s  capacity,  another  possibility  (although  far  less  likely) 
is  that  not  enough  of  the  processor’s  capacity  was  utilized.  The  embedded  system  could  have  been 
built  with  a  less  powerful  (less  expensive)  processor.  Whatever  the  outcome,  time,  resources,  and 
money  have  been  wasted.  In  addition,  the  potential  for  the  ultimate  failure  of  the  design  has  been 
introduced  into  the  system.  It  is  essential,  then,  that  the  scheduling  theory  used  to  design  the 
embedded  system  be  accurate. 

1.2  Problem  and  Research  Objectives 

Requirements  specifications  for  embedded  systems  often  use  CPU  reserve  capacity  as  a  design 
parameter  (16,  23).  The  reserve  capacity  is  then  used  as  an  evaluation  criteria  when  determining 
whether  the  final  design  meets  specifications.  In  addition,  the  reserve  capacity  of  a  processor  is  a 
fundamental  limitation  on  how  much  work  a  given  design  can  perform  and  hence,  a  fundamental 
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limitation  on  the  expandability  of  the  design.  It  is  important,  then,  that  the  reserve  capacity  of  a 
processor  be  estimated  accurately  during  the  design  phase  before  the  system  is  built. 

Reserve  capacity  is  defined  as  the  amount  of  additional  processing  time  available  after  the 
processor  has  completed  a  pre-defined  amount  of  work.  It  is  expressed  as  a  percentage  of  a  pre¬ 
defined  total  execution  time  over  which  the  pre-defined  workload  is  distributed.  A  processor  with 
eight  units  of  processing  to  complete  in  ten  units  of  time  has  a  reserve  capacity  of  20%.  The  eight 
units  of  processing  time  includes  both  task  execution  time  as  well  as  any  system  overhead  incurred 
as  a  result  of  the  task  execution.  It  is  important  to  note  that  not  all  of  the  20%  reserve  capacity 
will  be  available  for  task  execution.  A  portion  of  it  will  be  consumed  by  system  overhead. 

System  overhead  can  be  informally  defined  as  the  cost  of  managing  system  resources  necessary 
to  execute  user  tasks.  If  the  cost  of  managing  those  system  resources  is  too  great,  user  tasks  can  miss 
their  deadlines,  even  when  sufficient  processing  capacity  exists.  Therefore,  reasonable  assurance  is 
needed,  early  in  a  system’s  design  that:  (1)  sufficient  reserve  capacity  is  maintained  as  dictated 
by  the  design,  and  (2)  that  the  system  overhead  is  not  so  co  tly  that  it  causes  user  tasks  to  miss 
deadlines. 

Rate  monotonic  analysis  (RMA)  has  been  proven  to  be  a  significant  benefit  in  both  the  area 
of  predicting  reserve  capacity  and  predictable  task  scheduling  (22).  Rate  monotonic  scheduling 
theory  was  first  introduced  by  Liu  and  Lay  land  (11).  The  name  of  the  scheduling  theory  reflects 
the  strategy  used  to  schedule  processes  or  tasks.  Tasks  are  given  execution  priorities  based  solely 
on  their  rate  (how  often  they  execute).  The  higher  the  rate  of  the  task,  the  higher  the  priority  (i.e. 
a  monotonic  ally  increasing  function  of  the  rate).  Although  to  a  lesser  degree  than  many  scheduling 
theories,  the  rate  monotonic  algorithm  also  suffers  from  a  discrepancy  between  what  is  predicted 
to  occur  and  what  is  observed  on  a  real  machine  where  system  overhead  is  an  unavoidable  factor. 
This  discrepancy  leads  to  the  following  research  objectives. 
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1)  To  demonstrate  that  intimate  knowledge  of  the  entire  runtime  environment  is  not  re¬ 
quired  to  make  an  accurate  determination  of  reserve  capacity  and  schedulability  -  that 
is,  a  subset  of  key  runtime  parameters  is  sufficient. 

2)  To  provide  insight  into  an  application  task’s  interaction  with  the  runtime  environment 
during  execution. 

3)  To  develop  a  parameterized  model  of  a  runtime  environment  which  will  provide  a  con¬ 
servative  determination  of  task  schedulability  and  processor  reserve  capacity. 

1.2.1  Research  Hypothesis  The  primary  hypothesis  of  this  research  is  that  any  system  over¬ 
head  (system  tasks  executed  at  other  than  rate  monotonic  priorities)  has  the  same  effect  on  task 
schedulability  as  a  lower  priority  application  task  blocking  the  execution  of  a  higher  priority  user 
task.  A  natural  result  of  this  hypothesis,  if  true,  is  that  system  overhead,  sufficiently  characterized 
and  accurately  measured,  can  be  modeled  in  the  same  manner  as  user  task  priority  inversion  or 
non-preemptable  sections  of  code.  The  ability  to  accurately  predict  the  effect  of  system  overhead 
can  significantly  reduce  the  risk  associated  with  estimating  processor  capacity  requirements  and 
determining  task  schedulability  early  in  the  design  of  a  system. 

1.2.2  Scope  This  research  effort  was  limited  to  a  uniprocessor  executing  two  classes  of  task 
sets:  independent  periodic  tasks  and  dependent  periodic  tasks.  Independent  means  that  the  tasks 
do  not  communicate  or  share  resources  (other  than  the  CPU).  Dependent  means  that  tasks  must 
synchronize  or  communicate  at  one  or  more  points  during  their  execution. 

1.3  Approach 

A  different  way  to  state  the  problem  this  research  investigated  is:  how  does  the  execution 
of  system  tasks  (or  overhead)  that  do  not  follow  the  priority  assignments  of  the  RMA  affect  the 
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reserve  capacity  of  the  processor  (clearly  it  decreases  it,  but  by  how  much?).  Further,  how  do  these 
same  system  tasks  affect  the  schedulability  of  the  user  task  set. 

The  general  approach  used  to  investigate  this  was:  (1)  predict  the  behavior  of  a  given  task  set 
by  modeling  the  runtime  system  tasks  and  the  user  task  sets  interaction  with  them,  (2)  download 
an  executable  image  of  that  user  task  set  to  the  target  processor  and  observe  the  actual  behavior. 
The  results  of  (1)  and  (2)  were  compared  to  refine  the  model  in  order  to  increase  its  accuracy.  The 
task  set  executed  on  the  target  processor  served  to  validate  the  model. 

The  behavior  of  a  given  task  set  was  determined  by  simulating  the  services  a  runtime  system 
provides  and  accounting  for  the  CPU  time  those  services  require.  For  example,  if  Task  A  requests 
synchronization  with  Task  B,  the  runtime  system  will  require  access  to  the  CPU  in  order  to  deter¬ 
mine  whether  Task  B  is  ready  to  synchronize.  If  Task  B  is  ready,  the  runtime  system  will  perform 
the  synchronization.  If  Task  B  is  not  ready,  the  runtime  system  will  place  Task  A  on  a  queue  to 
wait  for  Task  B.  The  amount  of  time  that  the  runtime  system  requires  the  CPU  will  directly  affect 
whether  user  task  deadlines  will  be  met.  More  specific  details  of  the  methodology  and  the  runtime 
system  model  are  found  in  Chapters  III  and  IV. 

The  tools  needed  to  support  this  approach  include:  a  higher  order  language  in  which  the  task 
set  is  written,  target  hardware,  a  method  of  identifying  and  measuring  system  tasks  in  order  to 
construct  a  model  of  them,  and  a  task  set  to  execute. 

1.3.1  High  Order  Language  Ada  was  chosen  as  the  Higher  Order  Language  (HOL)  for  the 
following  reasons:  (1)  Ada  is  the  official  HOL  of  the  DoD  and  therefore  research  related  to  its  use 
in  embedded  systems  is  of  benefit  to  programs  using  Ada,  and  (2)  Ada  was  specifically  designed  for 
embedded  systems  and  contains  language  constructs  which  allow  for  investigation  of  a  task  set’s 
behavior  at  the  HOL  level.  While  Ada  was  used  in  this  research,  the  results  apply  to  any  HOL  in 
which  the  execution  of  user  tasks  follow  the  RMA  priority  assignment  scheme. 
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1.5.2  Target  Hardware  The  target  hardware  was  chosen  based  on  two  criteria:  (1)  the 
processor  should  be  representative  of  the  type  of  processor  used  in  embedded  systems  such  as 
robotics  and  other  control  applications,  and  (2)  an  Ada  cross-compiler  must  exist  and  be  readily 
available  for  the  target  processor.  Based  on  these  two  criteria,  the  Motorola  68020  processor  was 
chosen  as  the  target  processor  (14:1-5). 

1.3.3  System  Tasks  System  tasks  are  often  provided  by  the  compilation  system  in  the  form 
of  a  runtime  environment.  In  some  cases  they  are  developed  in  conjunction  with  the  application 
tasks.  In  either  case,  to  determine  the  effect  of  the  environment  on  the  user  task  set,  the  system 
functions  must  be  identified  and  measured.  The  Ada  Compilation  Evaluation  Capability  (ACEC) 
developed  for  the  Avionics  Directorate  (WL/AAAF)  of  Wright  Laboratory  at  Wright-Patterson 
Air  Force  Base,  Ohio,  was  used  to  identify  and  measure  these  functions.  Specifically,  the  following 
items  were  measured: 

1)  context  switching  time 

2)  DURATION  accuracy 

3)  task  synchronization 

4)  CLOCK  evaluation 

5)  TIME  and  DURATION  evaluation 

6)  DELAY  function  and 

7)  interrupts 

1.3.4  Task  Set  The  driving  criteria  in  choosing  a  task  set  for  this  research  was  that  the  work 
performed  by  a  given  task  should  be  accurately  characterized,  easily  measurable,  and  repeatable. 
Further,  the  amount  of  work  performed  by  the  task  set  should  be  representative  of  that  executed 
by  read-time  embedded  applications.  The  amount  of  work  performed  is  of  primary  importance  due 
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to  the  objective  of  the  research.  That  is,  the  purpose  of  the  task  set  is  not  to  determine  how 
many  MIPS  or  MFLOPS  a  processor  can  execute,  but  rather  to  ensure  a  given  amount  of  work  was 
performed. 

To  generate  this  task  set,  the  Hartstone  benchmark  developed  by  the  Software  Engineering 
Institute  (SEI)  was  used.  Three  classes  of  task  sets  have  been  defined:  (1)  periodic  (harmonic), 
(2)  periodic  (non-harmonic),  and  (3)  periodic  (harmonic)  with  synchronization.  Periodic  tasks 
are  some  of  the  most  common  tasks  in  a  real-time  system  (1:5).  The  harmonic  frequency  (task 
frequencies  that  are  integer  multiples  of  each  other)  was  chosen  since  that  will  result  in  a  high 
theoretic  utilization  for  the  RMA.  Non-harmonic  frequencies  were  chosen  because  they  have  a 
low  theoretic  utilization.  Each  of  the  classes  of  task  sets  will  be  observed  while  varying  various 
parameters  of  the  task  set:  work  performed,  frequency  of  execution,  and  synchronization.  A  block 
diagram  of  the  test  bed  is  shown  in  Figure  1.1  and  a  description  of  each  component  in  the  test  bed 
can  be  found  in  Section  3.3,  Page  3-7. 


Vax 

68020 

(Host) 

XD  Ad*  Croat 
CcmpMar 

Extant*  Imao** 
(Hannan*.  ACEC) 

Single 

Board 

Computer 

B*nctimark 

B*ncfmark  Rtauto 

(Target) 

*  ACEC 

(Communication  vta  RS-232) 

Figure  1.1.  Test  Bed  Block  Diagram 


1.4  Assumptions 

Assumptions  about  various  aspects  of  this  research  include: 

1)  The  timing  characteristics  of  the  runtime  environment  (context  switch,  rendezvous,  etc.) 
will  be  accurately  determined  through  the  ACEC  test  suite. 
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2)  The  Hartstone  benchmark  reserve  capacity  and  measurement  of  the  processor  capacity 
in  Whetstones  is  accurate. 

3)  The  pipeline  architecture  of  the  MC68020  will  not  introduce  any  significant  error  into  the 
timing  measurements.  A  hardware  pipeline  can  increase  execution  speed  by  overlapping 
the  execution  of  instructions  at  the  microcode  level.  Whether  this  optimization  can 
occur,  however,  is  highly  dependent  state  of  the  pipeline  (e.g.  the  particular  set  of 
macro  instructions  in  the  pipeline)  and  therefore  may  not  occur  consistently  in  every 
case.  The  assumption  being  made  >s  that  any  error  this  may  introduce  into  the  timing 
measurements  is  so  small  that  it  will  not  materially  affect  the  accuracy  of  those  timing 
measurements. 

1.5  Organization 

The  remainder  of  the  document  is  organized  in  the  following  manner: 

1)  Chapter  II  contains  a  review  of  literature  used  in  the  course  of  this  research. 

2)  Chapter  III  presents  a  more  detailed  description  of  the  research  methodology  used  and 
the  test  cases  used  to  validate  the  runtime  system  model. 

3)  Chapter  IV  contains  a  description  of  the  requirements,  design,  and  functional  testing 
of  the  model. 

4)  Chapter  V  presents  the  results  of  the  validation  tests. 

5)  The  results,  conclusions,  and  recommendations  of  this  research  are  contained  in  Chap¬ 
ter  VI. 

6)  Appendix  A  documents  the  development  and  analysis  of  the  equation  used  to  model 
the  XD  Ada  runtime  system  implementation  of  the  Ada  delay  statement.  In  addition, 
it  contains  the  raw  data  used  to  develop  the  equation. 
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7) 

8) 
9) 

10) 

11) 


Appendix 

Appendix 

Appendix 

Appendix 

Appendix 


B  presents  the  analysis  of  the  XD  Ada  clock  update  function. 

C  contains  the  raw  validation  data. 

D  contains  the  source  code  for  the  model  and  is  available  upon  request. 
E  contains  the  raw  ACEC  data  and  is  available  upon  request. 

F  is  a  user’s  manual  for  the  model  and  is  available  upon  request. 
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II.  Review  of  Current  Literature 


2.1  Organization 

This  chapter  is  organized  into  two  sections.  The  first  section  contains  literature  dealing  with 
hard  real-time  scheduling  algorithms,  especially  RMA  and  extensions  to  RMA.  The  second  section 
covers  literature  dealing  with  the  performance  measurement  of  hard  real-time  systems. 

2.2  Scope 

Much  of  scheduling  theory  deals  with  applications  in  which  a  statistically  fast  response  is  ac¬ 
ceptable.  These  scheduling  theories  strive  to  ensure  that  no  task  within  a  system  is  long  deprived  of 
the  resource  it  is  requesting.  Personal  computers,  mainframe  computers,  communications  networks, 
and  virtually  any  multi-user  system  fall  into  this  category.  Scheduling  theories  in  (hard)  real-time 
systems,  in  contrast,  will  strive  to  meet  deadlines  set  by  the  design  even  at  the  cost  of  never  execut¬ 
ing  lower  priority  tasks.  This  review  will  be  limited  to  literature  that  addresses  scheduling  theories 
used  in  real-time  systems  and  the  performance  measurement  of  real-time  systems. 

2.3  Overview  of  Common  Scheduling  Theories 

In  any  computer  system,  the  scheduling  theory  (or  scheduling  algorithm)  determines  when 
and  by  whom  system  resources  are  utilized.  In  a  real-time  system,  an  additional  constraint  of  a 
deadline  is  added.  The  scheduling  theory  in  a  real-time  system  not  only  determines  when  and  who 
gets  system  resources  but  additionally,  the  “when  and  who”  is  subject  to  higher  priority  tasks  not 
missing  their  deadlines.  Severed  methods  have  been  developed  to  solve  the  problem  of  allocating 
system  resources  in  this  manner  and  they  include  the  following  strategies  (12): 

1)  shortest- process- time  first 

2)  earliest-deadline  first 
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3)  shortest-slack- time  first 


4)  cyclic  executive 

5)  fixed  priority 

2.3.1  Shortesi-process-time  first  As  the  name  suggests,  tasks  that  require  the  least  amount 
of  CPU  time  are  given  priority  in  this  scheduling  strategy.  A  cursory  analysis  of  shortest-process¬ 
time  first  reveals  a  characteristic  that  precludes  this  scheduling  strategy’s  use  in  a  hard  real-time 
system.  The  shortest-process-time  first  does  not  take  into  account  any  deadlines  associated  with 
the  task.  Consider  the  periodic  tasks  shown  in  Table  2.1: 


Table  2.1.  Shortest-process-time  first  task  set 


Tasks 

Process  Time 

Period 

Deadline 

Task  A 

1 

10 

end  of  period 

Task  B 

3 

6 

end  of  period 

Task  C 

4 

7 

end  of  period 

Assuming  the  worst  case  phasing  and  ignoring  system  overhead,  Task  A  will  run  first  and 
complete  execution  at  T  =  1  before  its  deadline,  Task  B  will  then  run  completing  its  execution  at 
T  =  4  before  its  deadline,  Task  C  would  then  rim  but  not  complete  execution  until  T  =  8,  one  time 
unit  past  its  deadline. 


2.3.2  Earlicst-deadline  first  Earliest-deadline  first  assigns  priority  to  the  task  with  the  clos¬ 
est  deadline  at  any  given  point  in  time.  The  earliest-deadline-first  algorithm  is  optimal  in  the  sense 
that  if  a  successful  schedule  for  a  set  of  tasks  is  possible,  this  algorithm  will  produce  one  (11). 
The  drawback  to  this  algorithm,  in  a  real-time  environment  is  twofold:  (1)  it  is  computationally 
expensive  to  determine  whether  a  set  of  tasks  can  be  scheduled  at  an  arbitrary  instant  in  time,  and 
(2)  if  the  processor  utilization  is  greater  than  100%  (i.e.  the  processor  is  in  an  overload  condition) 
the  algorithm  will  fail  unpredictably,  allowing  a  task  to  execute  even  though  it  has  no  chance  of 
meeting  its  deadline  (12).  In  contrast  with  shortest-process-time  first  scheduling  which  did  not 
account  for  deadlines,  shortest-deadline  does  not  account  for  processing  time. 
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2.S.S  Shortest- slack-time  first  Shortest-slack-time  first  executes  the  task  which  has  the  min¬ 
imum  difference  between  its  deadline  and  the  processing  time  remaining.  In  the  same  manner  as 
earliest-deadline  first,  shortest-slacktime  first  is  computationally  expensive.  It  also  has  the  effect, 
in  practice,  of  delaying  a  task’s  execution  until  any  preemption  at  all  will  cause  the  task  to  miss 
its  deadline.  Therefore,  this  algorithm  is  seldom  used  (12). 

2.3.4  Cyclic  executive  The  cyclic  executive  model  is  the  traditional  scheduling  solution  of 
many,  if  not  most,  hard  real-time  systems  (22).  With  a  cyclic  executive,  task  executions  are 
explicitly  interleaved  such  that  the  deadlines  of  each  task  can  be  guaranteed.  The  schedule  is  laid 
out  prior  to  execution  so  the  computational  expense  of  determining  a  schedule  is  minimal.  A  key 
advantage  to  the  cyclic  executive  is  the  predictability  of  the  execution  times.  As  long  as  task 
execution  times  are  bounded,  task  deadlines  are  guaranteed  to  be  met. 

A  cyclic  schedule  is  created  in  the  following  manner  (3).  First,  the  schedule  is  divided  into 
a  fixed  time  interval  called  a  major  cycle  (see  Figure  2.1).  This  length  of  the  major  cycle  must 
be  the  least  common  multiple  of  the  task  periods  in  order  to  ensure  the  proper  periodicity  of  the 
tasks.  Each  major  cycle  is  divided  into  frames  or  minor  cycles.  Minor  cycle  boundaries  correspond 
to  points  where  the  proper  timing  is  enforced  through  a  timer  interrupt.  Due  to  this  timing 
enforcement,  the  minor  cycle  can  be  no  longer  than  shortest  period  of  the  process  being  scheduled. 
If  a  task  requires  an  amount  of  processing  time  that  is  greater  than  one  frame,  the  processing  time 
must  be  broken  into  several  subactions  or  chunks  and  distributed  across  several  frames.  Unless  a 
mode  change  occurs  (such  as  system  shutdown)  the  major  cycle  is  continously  repeated. 

The  cyclic  executive  is  a  fragile  algorithm  in  two  important  aspects.  If  a  task  requires  more 
frames  to  complete  its  execution  than  it  has  been  allotted  by  the  schedule,  a  frame  overrun  is  said 
to  have  occurred.  Two  actions  typically  take  place  when  a  frame  overrun  occurs;  either  the  task 
is  aborted  or  an  empty  frame  within  the  major  cycle  can  be  used  to  handle  the  extra  execution. 
Of  course,  depending  on  the  application,  either  solution  may  not  meet  the  timing  constraints  (3). 
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The  fragility  is  also  manifest  when  designing  a  cyclic  executive  schedule.  Consider  the  following 
example  (22).  A  task  set  has  periods  of  100  :  150  :  350  =  2:3:7.  A  minor  cycle  of  50  would 
require  a  major  cycle  of  42  minor  cycles.  Any  change  in  the  design,  periods  of  the  tasks,  or  CPU 


time  required  by  the  task  would  require  the  schedule  be  reaccomplished.  This  entails  a  significant 


effort,  especially  if  it  occurs  late  in  the  design  phase.  Another  problem  is  that  much  of  the  processor 


capacity  can  remain  unused  if  the  task’s  worst  case  execution  time  is  much  greater  than  its  typical 


case  execution  time. 


Ma|of  Cyd* 


Minor  Cyd*  (Frame) 


Alocatcd  CPU  Tim* 


Task  A  TaskB  Task  C  Task  A 

(Emcuton  not  (Exccukon 

yatcompM*)  complete) 


Figure  2.1.  Cyclic  Executive  Schedule 


2.S.5  Rate  Monotonic  A  fixed  priority  algorithm  executes  tasks  based  on  a  priority  deter¬ 
mined  prior  to  execution.  The  RMA  is  a  variant  of  the  fixed  priority  scheduler.  In  the  seminal 
paper  on  RMA  (11)  it  was  shown  that  a  schedule  will  always  exist  for  task  set  with  priorities 
assigned  according  to  the  RMA  on  a  processor  whose  utilization  is  below  a  certain  bound. 

Tasks  are  assigned  static  priorities  based  solely  on  their  rate  (bow  often  they  execute).  The 
higher  the  rate  of  the  task,  the  higher  the  priority  (i.e.  a  monotonically  increasing  function  of  the 
rate).  Essentially,  Liu  and  Lay  land  established  that  if  the  sum  of  the  ratios  of  the  time  to  execute  a 
set  of  tasks  and  the  periods  of  the  tasks  is  less  than  or  equal  to  n(2*/n  -  1),  (0.693  as  the  number  of 
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tasks  approaches  oo)  then  those  tasks  can  be  scheduled  using  rate  monotonic  priority  assignment. 
This  relationship  is  expressed  by  the  following  equation. 

<  U(n)  =  n(21/"  -  1) 

where  n  is  the  number  of  tasks,  Ci  is  the  time  to  execute  task  i  and  T,  is  the  period  of  task  i. 

This  algorithm  was  a  landmark  achievement  since  it  separated  the  functional  correctness  of 
a  task  from  its  timing  characteristics.  As  long  as  the  sum  of  the  set  of  task’s  ratios  is  less  than 
or  equal  to  U (n)  the  task  set  can  be  scheduled  without  regard  to  any  other  factor.  In  fact,  this 
property  has  the  added  benefit  that  even  during  processor  utilization  greater  than  U (n)  (even  if 
U(n)  is  greater  than  1),  the  set  of  tasks  whose  ratio  is  less  than  U(n)  (which  is  called  the  stable 
set)  is  guaranteed  to  meet  their  deadlines.  Thus,  the  RMA  is  a  stable  algorithm  during  overload 
conditions  for  the  tasks  in  the  stable  set. 

The  theory,  however,  is  limited  by  assumptions  that  the  authors  made.  First,  the  tasks 
are  assumed  to  be  periodic  or  executed  on  a  regular  basis  (e.g.  every  5  milli-seconds).  Second, 
task  communication  was  not  accounted  for.  Finally,  the  tasks’  execution  times  are  assumed  to  be 
bounded  by  a  constant.  These  assumptions  have  been  relaxed  by  subsequent  research. 

2.3.6  Extensions  to  RMA  For  all  its  advantages,  the  RMA  processor  utilization  bound  of 
0.693  for  guaranteed  schedulability  is  frequently  limiting  in  practice.  Lehoczky,  et  al.  extended 
that  bound  to  0.88  for  a  randomly  chosen  (or  average  case)  set  of  tasks  (9).  A  theorem  was  derived 
to  determine  exactly  if  a  given  task  set  could  be  scheduled.  The  average  case  behavior  of  a  task 
set  is  theoretically  interesting  because  it  showed  that  the  rate  monotonic  theory  is  applicable  to  a 
wider  portion  of  realistic  problems. 

The  average  case  described,  however,  suffers  from  a  slow  convergence.  That  is,  a  large  task 
set  is  needed  for  the  behavior  to  be  exhibited.  The  exact  characterization  of  a  given  task  set  is  more 
applicable  to  this  research.  The  theorem  derived  can  determine  that,  even  though  the  utilization 
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may  be  greater  than  the  upper  bound  determined  by  Liu  and  Layland,  the  tasks  can  nevertheless 
be  scheduled.  The  theorem  checks  each  and  every  scheduling  point  of  the  task  set.  If  a  schedule 
exists,  it  will  be  found  by  the  following  theorem  (9). 

A  set  of  n  independent  periodic  tasks  scheduled  by  the  rate  monotonic  algorithm  will  always 
meet  its  deadlines,  for  all  task  phasings,  if  and  only  if 

V»,l  <  i  <  n,min(£)=i  Cj  7T*  T^l)  <  1 
(k,l)€Ri 

where  Cj  and  7}  are  the  execution  time  and  period  of  task  tj  respectively  and  R,  =  {(k,l)  |  1  .< 
k<i,l  =  1,  ...,  Lj£j}. 

Note  that  although  this  theorem  states  “scheduled  by  the  rate  monotonic  algorithm”  it  will, 
in  fact,  determine  if  any  schedule  exists  for  any  task  set  using  a  fixed  priority  assignment  scheduling 
algorithm. 

2.3.7  Task  Synchronization  Dependent  tasks  (or  tasks  that  synchronize)  present  a  problem 
for  RMA.  When  tasks  synchronize,  a  higher  priority  task  may  be  required  to  delay  its  execution  to 
wait  for  a  lower  priority  task.  This  requirement  to  wait  for  a  lower  priority  task  is  contrary  to  the 
primary  principle  of  RMA,  namely,  that  a  higher  priority  task  will  always  preempt  a  lower  priority 
task.  Common  synchronization  protocols  include  semaphores,  monitors,  and  Ada  rendezvous.  Use 
of  these  synchronization  protocols  could  lead  to  a  high  priority  task  being  blocked  indefinitely. 
Consider  the  following  example. 

A  task  set  consists  of  five  tasks  7\,  7j,  Ts,  T4,  7s  where  the  priorities  ranked  from  7s  (highest) 
to  Tj  (lowest).  T\  and  7b  share  a  common  memory  location  through  a  semaphore.  Suppose  T\  locks 
a  semaphore  and  is  subsequently  preempted  by  7b.  7s  also  needs  the  semaphore  but  must  wait 
for  T\  to  unlock  it.  In  the  mean  time,  T\  is  subject  to  preemption  from  Tj,  T3,  and  T+,  multiple 

f 
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times  causing  the  highest  priority  task,  T5,  to  wait  arbitrarily  long  to  execute.  Clearly,  this  type 
of  situation  is  unacceptable  in  a  hard  real-time  environment. 

For  this  reason,  the  priority  ceiling  protocol  was  developed  (22).  The  protocol  has  two  basic 
tenets.  First,  if  a  task  blocks  the  execution  of  any  higher  priority  task,  it  will  inherit  the  priority 
of  the  highest  priority  task  blocked.  Second,  a  task  is  only  allowed  to  enter  a  critical  section  if  the 
section  will  always  execute  at  a  priority  higher  than  the  inherited  priority  level  of  any  preempted 
critical  sections.  This  protocol  will  ensure  freedom  from  mutual  deadlock  and  provide  a  bounded 
blocking  time.  A  high  priority  task  using  the  priority  ceiling  protocol  will  be  blocked  at  most  once 
by  a  lower  priority  task. 

Given  these  properties  of  the  priority  ceiling  protocol,  the  maximum  time  a  higher  priority 
task  can  be  blocked  is  equivalent  to  decreasing  its  deadline  by  the  same  amount.  If  a  task’s  deadline 
is  at  T  =  100  and  it  can  be  blocked  at  most  by  30  units  of  time,  its  equivalent  deadline  is  now 
T  —  70. 

To  account  for  this  blocking,  the  following  equation  applies: 

A  set  of  n  independent  periodic  tasks  scheduled  by  the  rate  monotonic  algorithm  and  using 
the  priority  ceiling  protocol  will  always  meet  its  deadlines,  for  all  task  phasings,  if  and  only  if  (21) 


Vi,  1  <  i  <  n,  min(Y2  Cj  -~r  ^ r )  <  1 

ITk  Tj  1  lTk  lTk '  ~ 


(2.1) 


(k,l)€Ri 


where  Cj  and  3)  are  the  execution  time  and  period  of  task  13  respectively,  ft,  =  {(k,  /)  |  1  <  Jk  <  i, 
/  =  !,...,  [^-j  }  and  ft,-  is  the  worst  case  blocking  time  for  r<. 
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2.4  Performance 


This  section  summarizes  the  literature  dealing  with  the  performance  measurement  of  com¬ 
puter  systems.  Specifically,  this  section  reviews  literature  that  addressed  (1)  how  to  measure  the 
performance  of  an  embedded  target,  (2)  pitfalls  associated  with  performance  measurement  of  com¬ 
puters,  and  (3)  factors  that  could  distort  the  performance  measurement  of  a  given  system. 

2.4. 1  Performance  measurement  of  an  Ada  compilation  system  Measuring  the  performance 
of  a  compilation  system  is  a  complex  procedure  (4:760).  Three  aspects  of  this  measurement  are 
critical  for  success:  isolating  the  feature  to  be  measured,  repeatability,  and  sufficient  accuracy  to 
obtain  meaningful  results.  Typically,  isolating  the  feature  to  be  measured  is  achieved  by  executing  a 
control  loop  without  the  feature  to  be  measured,  and  a  loop  containing  the  feature  to  be  measured. 
Theoretically,  the  time  difference  between  these  loops  is  the  time  required  to  execute  the  feature 
under  test.  There  are  several  caveats  however.  First,  if  the  compilation  system  clock  is  being 
used  to  measure  time,  it  must  be  of  sufficient  precision  relative  to  the  feature  being  measured,  or 
inaccurate  results  will  be  obtained.  Second,  steps  should  be  taken  to  ensure  that  any  compiler 
optimization  does  not  interfere  with  the  measurement  by  optimizing  out  the  very  feature  that  is 
being  measured. 

As  a  case  in  point,  during  testing  done  by  the  Software  Engineering  Institute,  a  certain 
benchmark  test  was  consistently  returning  negative  time  results  (26).  The  cause  was  eventually 
determined  to  be  related  to  the  Ada  CLOCK  resolution  of  the  particular  compilation  system 
Factors  which  may  cause  variations  are  (26):  clock  overhead,  optimization,  memory  allocation, 
garbage  collection,  and  other  operating  system  effects. 

In  order  to  sufficiently  characterize  the  behavior  of  an  Ada  compilation  system  relevant  to 
real-time  performance,  the  following  elements  should  be  measured  (4:765): 

1)  subprogram  calls 
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2)  task  activation 


3)  task  termination 

4)  task  synchronization 

5)  CLOCK  evaluation 

6)  TIME  and  DURATION  evaluation 

7)  DELAY  function 

8)  garbage  collection  and 

9)  interrupts 

Three  benchmarks  have  been  generally  available  to  test  these  important  aspects  of  an  Ada 
compilation  system  (6): 

1)  the  University  of  Michigan  Ada  benchmarks, 

2)  the  Performance  Issues  Working  Group  benchmarks  (or  PIWG,  an  Association  of  Com¬ 
puting  Machinery  special  interest  group),  and 

3)  the  Ada  Compiler  Evaluation  Capability  (ACEC). 

Over  the  course  of  development  of  these  three  benchmarks,  the  functionality  of  the  University 
of  Michigan  benchmarks  and  PIWG  benchmarks  has  been  incorporated  into  the  ACEC. 

The  ACEC  Reader’s  Guide  (17)  defines  what  the  ACEC  is  designed  to  accomplish,  the  in¬ 
tended  users  of  the  package,  and  the  rationale  of  the  design.  The  ACEC  was  designed  to  compare 
the  runtime  performance  of  different  compiler  implementations  as  well  as  to  compare  various  non¬ 
performance  related  aspects  of  a  compiler  such  as:  assessment  of  a  symbolic  debugger,  library 
system  management,  and  diagnostic  message  clarity.  The  ACEC  tests  incorporate  many  features 
to  test  for  and  to  defeat  many  of  the  compiler  optimizations  or  other  effects  that  would  result  in 
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inaccurate  results.  This  test  suite  is  widely  used  by  compiler  manufacturers  to  test  their  compilers 
prior  to  release. 

2-4-2  Task  set  performance  measurement  A  limitation  with  benchmarks  such  as  the  ACEC 
is  that  they  focus  on  a  single  activity  or  aspect  of  a  compilation  system.  They  do  not  attempt  to 
measure  the  performance  of  a  set  of  activities  and  whether  or  not  this  set  of  activities  (or  tasks) 
meet  a  given  set  of  performance  criteria.  In  fact,  trying  to  draw  general  conclusion  from  such 
measurements  is  difficult  and  risky  (1).  Since  a  real-time  system  will  be  performing  many  tasks, 
though,  it  is  important  to  establish  that  the  given  set  of  performance  criteria  is  being  met. 

The  Hartstone  benchmark  is  one  such  benchmark  that  attempts  to  quantify  whether  or  not 
a  set  of  activities  meet  a  given  set  of  performance  criteria.  The  requirements  document  for  the 
Hartstone  (1)  defines  an  operational  concept  and  requirements  for  a  set  of  benchmarks  designed  to 
test  the  ability  of  a  system  to  run  hard  real-time  applications.  The  Hartstone  was  not  designed  to 
test  a  particular  scheduling  paradigm  or  programming  language.  Although  the  first  implementation 
of  it  was  in  Ada,  it  was  designed  to  be  translated  to  any  language  being  utilized  for  hard  real-time 
systems. 

The  benchmark  was  designed  to  have  the  following  characteristics  (1). 

1)  It  spans  the  entire  hard  real-time  problem  domain  -  it  contains  periodic  and  aperiodic 
event  driven  tasks.  The  aperiodic  events  are  both  user-initiated  and  interrupt-driven. 

Task  synchronization,  access  to  common  data,  mode  changes  and  distributed  processing 
are  included. 

2)  The  benchmark  tests  increase  in  complexity.  That  is,  in  the  series  of  tests,  simple  or 
(presumably)  easy  to  accomplish  tasks  are  run  first  followed  by  tests  that  are  considered 
more  difficult. 
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3)  Each  test  has  a  baseline  requirement  and  a  strategy  for  increasing  that  requirement  to 
stress  the  system  along  a  number  of  dimensions.  For  instance,  the  periodic  workload 
could  be  increased  as  other  factors  remain  constant.  Other  dimensions  that  can  be 
independently  varied  are:  processing  load,  aperiodic  events,  and  task  frequency. 

4)  Each  test  is  self- verifying.  The  test  itself  verifies  that  the  computations  are  being 
performed  correctly  and  that  it  met  its  deadline. 

5)  The  computational  load  is  synthetic.  In  the  case  of  the  Hartstone,  a  self-verifying  version 
of  the  Whetstone  is  used  for  the  computational  load.  This  ensures  that  when  comparing 
various  processors  or  architectures,  the  same  amount  of  work  is  being  performed. 

6)  A  relative  figure  of  merit  is  assigned  for  each  test  that  clearly  distinguishes  between 
actual  work  being  done  and  system  overhead.  Therefore,  the  more  useful  measure  of 
maximum  utilization  prior  to  a  deadline  being  missed  can  be  determined  rather  than 
maximum  throughput. 

The  Hartstone  consists  of  five  series  of  tests.  Table  2.2  lists  the  main  objective  of  each  test. 


Table  2.2.  Hartstone  Tests 


Test  Series 

Measurement  Objective 

PH 

Periodic  Tasks,  Harmonic  Frequencies 

PN 

Periodic  Tasks,  Non-Harmonic  Frequencies 

AH 

Same  as  PH  with  APeriodic  Tasks  Added 

SH 

Same  as  PH  with  Synchronization  Added 

SA 

Same  as  PH  with  APeriodic  Tasks  and  Synchronization  Added 

2.5  Summary  and  Conclusions 

Scheduling  theories  have  received  much  attention  in  the  literature.  Due  to  the  computational 
expense  of  most  scheduling  schemes  only  the  cyclic  executive  and  fixed  priority  scheduling  has  seen 
wide  use  in  the  real  time  applications.  A  common  missing  element  in  most  literature,  however,  is 
that  system  overhead  issues  such  as  interrupts,  task  synchronization,  and  other  functions  necessary 
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for  the  operation  of  a  real  system  are  not  addressed  in  a  comprehensive  manner.  That  is,  most 
literature  either  ignores  system  effects  completely  or  only  addresses  a  subset  of  system  effects, 
while  ignoring  other  effects  that  have  an  equally  pronounced  impact  on  the  schedulability  of  a 
given  task  set.  The  end  result  is  that  if  a  software  engineer  needs  to  determine  the  feasibility  of  a 
particular  schedule,  a  model  must  be  constructed  from  a  variety  of  sources  and  is  likely  to  be  tied 
to  a  particular  runtime  system.  A  later  change  in  the  runtime  system  might  require  another  model 
be  constructed. 

In  order  to  account  for  system  effects,  they  must  be  measured.  To  measure  individual  features, 
the  standard  approach  is  to  isolate  the  feature  to  be  measured  by  executing  a  control  loop  without 
the  feature,  and  then  a  loop  containing  the  feature  to  be  measured.  The  time  difference  between 
these  loops  is  the  time  required  to  execute  the  feature  under  test.  While  this  method  will  give  useful 
results,  it  is  not  sufficient  to  enable  one  to  draw  any  general  conclusions  about  the  behavior  of  the 
system  while  running  a  given  task  set.  For  instance,  while  you  may  know  that  a  particular  runtime 
environment  takes  x  microseconds  to  reclaim  unused  memory  (garbage  collection),  using  the  control 
loop  approach  gives  no  information  about  under  what  conditions  unused  memory  is  reclaimed.  In 
fact,  when  a  runtime  system  does  garbage  collection  may  directly  affect  the  schedulability  of  the 
user  task  set.  In  order  to  determine  the  behavior  of  a  system  which  takes  into  account  system 
effects  that  occur  during  the  execution  of  a  task  set,  other  measurement  techniques  are  used.  One 
such  approach  is  to  execute  a  task  set  that  performs  a  known  amount  of  work  and  to  increase  the 
workload  (or  another  parameter  of  interest)  and  observe  the  effect  on  the  schedulability  of  the  task 
set. 

This  research  will  focus  on  the  construction  of  a  model  which  will  permit  a  schedulability 
determination  of  a  given  task  set  under  a  controlled  load.  It  will,  in  essence,  be  a  plant/load  simu¬ 
lation  of  a  runtime  system.  Load  simulations  are  widely  used  as  a  means  of  verification  of  various 
system  properties  (10).  The  contribution  this  research  makes  is  to  show  that  a  parameterized 
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model  of  the  runtime  system  (or  a  parameterized  load  simulation)  can  be  constructed  based  on  the 
measurement  of  a  subset  of  key  runtime  system  features  thereby  making  the  model  applicable  to  a 
wide  range  of  runtime  environments.  Not  only  will  the  model  determine  whether  a  particular  user 
task  set  can  be  scheduled  under  a  particular  runtime  system,  but  also  whether  it  can  be  scheduled 
under  any  runtime  system  with  the  same  parameters.  If,  in  fact,  the  runtime  system  is  being  de¬ 
signed  in  concert  with  the  user  tasks,  the  execution  budget  can  be  used  in  the  model  in  place  of 
the  actual  measurement  of  particular  runtime  system.  This  type  of  model  will  permit,  early  in  a 
system’s  design,  an  analysis  of  whether  a  particular  task  set  will  execute.  Additionally,  it  can  also 
be  used  to  determine  the  worst  case  overhead  a  particular  task  set  can  suffer  before  the  task  set 
will  no  longer  meet  its  deadlines. 
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III.  Methodology 


3.1  Introduction 

This  chapter  presents  the  research  methodology  used  to  construct  and  validate  a  task  schedul¬ 
ing  model,  RATESIM  (RATE  monotonic  scheduling  SIMulation),  which  predicts  the  behavior  of 
a  given  task  set.  Recall  that  the  objective  of  this  research  is  to  provide  a  means  of  determining, 
early  in  the  design  phase,  the  schedulability  of  a  given  user  task  set  while  taking  into  account  the 
effect  of  the  runtime  environment  (system  tasks)  in  which  that  user  task  set  must  execute.  The 
RATESIM  program  will  be  used  to  fulfill  this  objective. 

First,  the  system  tasks  are  identified  and  the  methods  to  measure  their  effects  are  presented. 
Next,  user  task  sets  (used  for  validation)  are  presented  along  with  the  objectives  of  each  validation 
test.  The  equipment  being  used  is  identified  and  the  test  bed  configuration  is  described.  Finally, 
the  data  to  be  gathered  and  the  statistical  analysis  of  that  data  is  discussed. 

3.2  Research  Methodology 

In  order  to  meet  the  objective  stated  above,  the  following  basic  research  methodology  was 

used. 

1)  Identify  the  system  tasks. 

2)  Measure  those  system  tasks  to  determine  the  amount  of  CPU  time  they  use  and  at  what 
frequency. 

3)  Define  a  user  task  set. 

4)  Predict  the  behavior  of  the  user  task  sets  based  on  the  system  tasks  and  determine  the 
effect  the  system  tasks  will  have  on  the  schedulability  of  the  given  task  set  (i.e.  will  the 
task  set  still  meet  all  its  deadlines?).  Specifically,  the  system  tasks  will  be  modeled  as 
a  blocking  factor  that  each  user  task  in  the  task  set  suffers. 


3-1 


5)  Construct  and  execute  the  user  task  set  on  the  target  processor  and  observe  whether 

or  not  the  prediction  was  accurate. 

6)  Go  to  step  3. 

The  above  methodology  will  serve  as  the  basic  framework  for  investigating  the  effect  system 
tasks  have  on  the  schedulability  of  a  user  task  set.  A  discussion  of  each  specific  step  follows. 

3.2.1  Identify  the  System  Tasks  System  tasks  are  those  functions  which  are  necessary  to 
manage  the  resources  of  an  embedded  system  but  nevertheless  do  not  directly  perform  useful  work 
from  the  perspective  of  the  user  task.  System  tasks  allow  or  facilitate  the  performance  of  useful 
work  by  user  tasks.  In  addition,  system  tasks  often  immediately  preempt  user  tasks,  without  regard 
to  any  user  deadlines. 

The  following  list  is  a  preliminary  set  of  system  tasks  which  will  affect  the  schedulability  of 
a  user  task  set.  These  were  identified  through  searching  existing  literature  (4,  26). 

1)  system  CLOCK  updates 

2)  context  switching  time 

3)  DELAY  resolution 

4)  interrupts 

5)  TIME  and  DURATION  evaluation 

6)  task  synchronization 

7)  task  activation 

8)  task  termination 

9)  garbage  collection 
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While  this  is  certainly  not  an  exhaustive  list  of  items  that  could  affect  a  user  task  set  when 
implemented  on  a  real  machine,  it  represents  those  that  have  the  most  pronounced  effect  (26). 
Dynamic  task  creation,  termination,  and  garbage  collection  are  system  tasks  not  included  in  the 
RaTESIM  model. 

3.2.2  Measure  the  System  Tasks  The  Ada  Compilation  Evaluation  Capability  (ACEC)  test 
suite  (version  3.0)  was  used  to  measure  the  various  system  tasks  which  affect  the  schedulability  of 
the  user  task  set.  The  ACEC  is  a  compiler  evaluation  benchmark  used  to  assess  the  capabilities 
of  Ada  compilation  systems.  Its  purpose  is:  (1)  to  allow  comparison  of  different  compilation 
systems  using  objective,  measured  data  and  (2)  to  determine  performance  characteristics  of  a  given 
compilation  system.  The  ACEC  is  intended  to  measure  many  aspects  of  am  Ada  compilation  system 
including:  capacity  limits,  symbolic  debuggers,  library  management  systems,  diagnostics,  compile 
time,  code  size,  and  execution  time.  Obviously,  this  research  will  limit  its  use  of  the  ACEC  to 
determine  the  execution  time  of  system  tasks  of  interest  in  the  compilation  system  executing  on 
the  target  hardware. 

To  measure  the  above  system  tasks,  runtime  performance  benchmarks  of  the  ACEC  were  used 
coupled  with  the  ACEC  Single  System  Analysis  (SSA)  tool.  The  SSA  tool  extracts  information 
implicit  in  relationships  between  various  test  problems.  The  SSA  major  report  categories  include: 
Language  Feature  Overhead,  Optimizations,  Run-time  System  Behavior,  and  Coding  Style  Vari¬ 
ations.  Over  1600  tests  are  included  in  the  ACEC  and  the  SSA  can  summarize  and  report  the 
performance  of  virtually  every  system  task  of  interest  in  a  variety  of  execution  modes. 

Figure  3.1  (18)  is  an  overview  of  the  ACEC.  The  area  surrounded  by  the  dashed  line  represents 
the  portion  of  the  ACEC  not  utilized  in  this  research.  A  detailed  description  of  the  ACEC  and  in 
depth  discussion  and  analysis  of  the  measurement  techniques  are  beyond  the  scope  of  this  research. 
These  details  can  be  found  in  the  documents  provided  with  the  ACEC  (17,  18,  19).  A  summary  of 
ACEC  results  are  contained  in  Chapter  V. 
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Figure  3.1.  Overview  of  the  ACEC 


3. 2.3  Predict  the  effect  -  RATESIM  The  effect  of  the  system  tasks  measured  by  the  ACEC 
on  the  user  task  set  is  determined  by  incorporating  the  execution  time  measurements  into  the 
RATESIM  model  and  then  submitting  the  user  task  set  to  RATESIM.  RATESIM  “executes”  the 
user  task  set  (e.g.  accounts  for  the  load)  and  determines,  based  on  the  ACEC  measurements,  the 
interaction  between  the  user  task  set  and  the  system  tasks. 

RATESIM  determines  whether  a  user  task  has  met  its  deadline  by  accounting  for  system  task 
and  user  task  utilization  of  the  CPU.  Since  it  knows  the  deadlines  of  user  tasks  it  can  detect  when 
a  user  task  has  missed  a  deadline. 

All  system  task  execution  times  are  parameterized  within  RATESIM  in  order  to  allow  for 
easy  modification  should  one  wish  to  model  a  different  runtime  system.  In  addition,  system  tasks 
not  specifically  parameterized  can  be  easily  added  by  supplying  the  system  task  parameters  to  the 
model.  The  most  significant  behavior  that  is  currently  embedded  within  the  RATESIM  model  (and 
therefore  not  easily  modified)  are:  (1)  a  fixed  priority,  preemptive,  event-driven  scheduling  strategy, 
and  (2)  system  tasks  will  always  preempt  user  tasks.  Priorities  of  user  tasks  sue  determined  using 
rate  monotonic  priority  assignment  (the  higher  the  rate  of  the  task,  the  higher  the  priority).  Other 
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embedded  behavior  includes  two  runtime  optimizations  considered  general  practice.  Details  about 
these  optimizations  and  the  RATESIM  design  is  contained  in  Chapter  IV.  RATESIM  validation 
details  are  in  Chapter  V. 

3.2.4  Run  the  task  set  The  user  task  sets  are  based  on  the  SEI  Hartstone  benchmark  version 
1.0  (7).  This  benchmark  provides  well-defined  tasks  and  allow  task  set  parameters  such  as  workload 
and  frequency  to  be  varied.  The  benchmark  tasks  sets  have  been  used  as  written  when  appropriate 
and  modified  as  needed  to  meet  the  objectives  of  this  research.  For  example,  the  Periodic  Tasks, 
Non-Harmonic  Frequencies  (PN  series)  benchmark  and  the  Periodic  Tasks,  Harmonic  Frequencies 
with  Synchronization  (SH  series)  benchmark  described  in  the  Hartstone  requirements  document 
(1)  have  not  yet  been  implemented.  Therefore,  the  current  Periodic  Tasks,  Harmonic  Frequencies 
(PH  series)  benchmark  was  modified  to  implement  the  PN  and  SH  series  requirements. 

The  following  task  sets  have  been  defined  for  use  to  validate  the  behavior  of  RATESIM.  For 
each  set,  the  measurement  objective  of  task  set  has  been  identified. 

3.2.4. 1  Task  Set  A  This  task  set  consists  of  five  periodic  tasks  (see  Table  3.1)  whose 
frequencies  are  integer  multiples  of  each  other  (harmonic).  This  task  set  represents  a  major  class 
of  real-time  applications.  It  has  a  high  theoretical  utilization  based  on  RMA.  Two  parameters  of 
this  task  set  are  varied,  the  work  performed  (Cj,  expressed  in  kilo-whetstones)  and  the  frequency 
(Tj).  The  objective  in  using  this  task  set  is  to  observe  the  interaction  between  the  system  tasks  and 
Cj.  As  Cj  is  increased,  the  system  overhead  should  initially  remain  constant  since  no  additional 
overhead  is  induced.  Conversely,  as  7)  is  increased,  user  task  CPU  utilization  should  decrease 
immediately  due  to  an  increase  in  task  switching  overhead. 

3. 2. 4. 3  Task  Set  B  This  task  consists  of  a  set  of  five  periodic  tasks  (see  Table  3.2) 
whose  frequencies  are  non-harmonic.  This  task  set  has  a  low  theoretical  utilization  based  on 
RMA.  The  difference  between  this  task  set  and  task  set  A  is  that  the  system  overhead  should  be 
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Table  3.1.  Task  Set  A  -  Periodic/Harmonic 


Task 

No. 

Frequency 

(Hertz) 

Kilo- Whetstones 
per  Period 

Kilo- Whetstones 
per  Second 

Requested  Workload 
Utilization 

1 

mum 

32 

64 

2 

16 

64 

u 

3 

8.00 

8 

64 

4.79% 

4 

16.00 

4 

64 

5 

32.00 

2 

64 

significantly  greater  to  start  with  due  to  the  non-harmonic  frequencies  of  the  tasks.  Non-harmonic 
relationships  between  tasks  will  often  defeat  optimizations  that  the  runtime  system  could  normally 
implement  with  harmonic  task  sets.  This  behavior  is  discussed  further  in  Chapter  V,  Section  5.5.2. 


Table  3.2.  Task  Set  B  -  Periodic/Non-Harmonic 


Task 

No. 

Frequency 

(Hertz) 

Kilo-Whetstones 
per  Period 

Kilo- Whetstones 
per  Second 

Requested  Workload 
Utilization 

2.00 

32 

64 

4.79% 

2.30 

16 

36.8 

4.59 

8 

36.7 

2.75% 

6.89 

4 

27.6 

5 

9.19 

2 

18.4 

1.38% 

3.2.4- 3  Task  Set  C  This  task  consists  of  a  set  of  five  periodic  tasks  in  two  different 
configurations(see  Tables  3.3  and  3.4).  The  task  set  frequencies  are  integer  multiples  of  each 
other  (harmonic)  and  they  have  synchronization  requirements.  The  parameter  to  be  varied  is  the 
frequency  of  each  task  in  the  task  set.  The  objective  of  this  task  set  is  to  validate  the  behavior 
of  the  model  during  synchronization.  Tasks  that  execute  a  workload  (Task  5  in  Task  Set  C2  does 
not)  have  an  initial  requested  utilization  of  4.79%  per  period. 


Table  3.3.  Task  Set  Cl  -  Periodic/Harmonic/Synchronization 


Task 

No. 

Frequency 

(Hertz) 

Kilo- Whets 
per  Period 

Kilo-Whets 
per  Second 

Entry  Call 
time  ( fis ) 

Accept  at 
at  time  (j*s) 

Accept 

Workload  (KW) 

mgm 

64 

n/a 

n/a 

n/a 

flKKSl 

mm; 

64 

n/a 

n/a 

n/a 

8.00 

8 

64 

n/a 

n/a 

n/a 

32.00 

4 

64 

n/a 

0 

0 

5 

32.00 

2 

64 

0 

n/a 

n/a 
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Table  3.4.  Task  Set  C2  -  Periodic/Harmonic/Synchronization 


Task 

No. 

Frequency 

(Hertz) 

Kilo- Whets 
per  Period 

Kilo- Whets 
per  Second 

Entry  Call 
at  time  (fis) 

Accept  at 
time  (ps) 

Accept 

Workload  (KW) 

1 

mssM 

32 

64 

n/a 

n/a 

n/a 

2 

mem 

16 

64 

n/a 

n/a 

n/a 

3 

8.00 

8 

64 

n/a 

n/a 

n/a 

4 

32.00 

4 

64 

n/a 

0 

2 

5 

32.00 

0 

64 

0 

n/a 

n/a 

3.3  Equipment 

Table  3.5  lists  the  equipment  being  used.  A  block  diagram  of  the  test  bed  is  shown  in 
Figure  3.2. 


Table  3.5.  Research  Equipment  and  software 


Equipment 

Comment 

Motorola  68020 

target  processor  (the  unit  under  test) 

Vaxstation  III 

development  computer  for  SW  benchmarks 

XD  Ada  cross-compiler 

Ada  compiler  for  68020 

Hartstone  benchmark 

test  cases 

ACEC  test  suite 

measure  compiler  runtime  performance 

3.3.1  Target  system  The  target  processor  is  a  Motorola  68020  on  the  MVME133A-20 
Monoboard  Microcomputer  (15).  The  MVME133A  consists  of  the  MC68020  microprocessor  and 
the  MC68881  coprocessor  both  running  at  a  clock  speed  of  20  MHz.  There  is  1  MByte  of  dynamic 
RAM  onboard. 


3.3.2  Host  system  The  host  system  is  a  Vaxstation  III  running  the  VMS  5.1  operating 
system.  Communication  to  the  target  is  provided  through  two  serial  ports.  One  serial  port  is  used 
to  download  the  kernel  and  application  code  and  the  other  is  used  as  a  debug  communications  port. 
In  this  research  the  debug  port  was  used  to  display  messages  from  the  application  code. 
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3.S.3  Compilation  System  The  compilation  system  used  was  the  System  Designers  XD  Ada 
MC68020  cross  compilation  system  (24).  XD  Ada  consists  of  a  cross-compiler,  development  tools 
(builder,  loader,  assembler,  librarian,  etc.),  debugger,  predefined  compilation  units,  and  a  run-time 
object  code  library. 


Figure  3.2.  Test  Bed  Block  Diagram 


3.4  Data 

Data  collected  during  this  research  came  from  three  sources:  the  Hartstone  benchmark,  XD 
Ada  runtime  kernel,  and  the  ACEC.  The  data  collected  from  those  sources  is  listed  in  Table  3.6. 
Table  3.7  explains  the  meaning  of  each  data  item. 


Table  3.6.  Research  Data 


Data  Item 

Source 

Task  Set 

Hartstone/  User  generated 

Raw  Speed 

Hartstone  benchmark 

Task  frequency 

Hartstone  benchmark 

Workload 

Hartstone  benchmark 

Met  Deadlines 

Hartstone  benchmark 

Missed  Deadlines 

Hartstone  benchmark 

Skipped  Deadlines 

Hartstone  benchmark 

Average  Late 

Hartstone  benchmark 

Task  Utilization 

Hartstone  benchmark 

Context  Switch  Time 

ACEC 

Delay  Time 

ACEC 

Rendezvous  Time 

ACEC 

Clock  Update  Time 

XD  Ada  kernel 
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Data  Item 


Comment 


Raw  Speed 


Task  frequency 


Workload 


Met  Deadlines 


Missed  Deadlines 


Skipped  Deadlines 


Average  Late 


Task  Utilization 


Context  Switch  Time 


Delay  Time 


Rendezvous  Time 


Clock  Update  Time 


Raw  CPU  speed  in  Kilo- Whetstones 


Number  of  times  per  second  the  task  is  required  to 
perform  the  requested  workload 


Amount  of  work  required  of  the  task  in  Kilo- Whetstones _ 

Number  of  times  during  the  test  that  the  task  successfully 
completed  its  workload  before  the  next  scheduled  activation  time 


Number  of  times  during  the  test  that  the  task  failed 

to  complete  its  workload  before  the  next  scheduled  activation  time 


Number  of  scheduled  activation  times  which  were  not  performed 
due  to  a  previously  missed  deadline 


Average  lateness  of  missed/skipped  deadlines 


Percentage  of  CPU  time  dedicated  to  user  tasks 


Worst  case  execution  time  to  perform  a  context  switch 


Actual  Delay  time 


Worst  case  execution  time  to  perform  a  rendezvous 


Worst  case  execution  time  to  update  system  clock 
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3.5  Data  Analysis 


The  data  collected  during  this  research  was  used  in  two  ways:  (1)  to  describe  the  runtime 
environment,  and  (2)  to  validate  the  RATESIM  model  behavior.  The  data  collected  using  the 
ACEC  test  suite  was  used  to  supply  execution  time  of  key  runtime  system  functions  -  this  served 
as  the  basis  for  the  description  of  the  runtime  system.  The  data  collected  Hartstone  benchmark 
served  as  the  standard  for  determining  “correct”  behavior  in  the  RATESIM  model.  Data  from  the 
Hartstone  benchmark  and  the  RATESIM  model  were  compared  and  any  significant  differences  in 
the  data  served  to  identify  deficiencies  in  RATESIM.  The  model  was  then  modified  to  correct  those 
deficiencies  and  the  tests  were  rerun. 

The  first  task  in  describing  the  behavior  of  the  runtime  environment  was  to  analyze  the  data 
gathered  by  the  ACEC  and  construct  a  model  of  the  individual  runtime  services  being  modeled 
by  RATESIM.  The  model  was  constructed  to  be  able  to  “execute”  independent  and  dependent, 
periodic  tasks.  The  following  runtime  services  from  the  runtime  system  were  needed  as  input  to 
the  model:  clock  update  time,  context  switch  time,  rendezvous  time,  and  DELAY  expiration  time. 
The  following  sections  summarize  the  analysis  that  was  performed  for  each  of  the  services. 

3.5.1  Clock  Update  Time  The  clock  update  of  an  Ada  runtime  system  is  the  system  function 
used  by  an  Ada  program  to  provide  any  time-related  requests  of  a  program  such  as:  TIME,  YEAR, 
SECONDS,  DELAY,  etc.  The  clock  update  service  is  typically  interrupt-driven,  periodic,  and  very 
short.  Even  though  it  is  typically  short,  it  is  a  runtime  function  which  will  be  a  source  of  non-rate 
monotonic  utilization  of  the  CPU  and  therefore  could  affect  the  schedulability  of  user  tasks. 

Since  the  clock  update  involves  a  relatively  small  amount  of  code,  it  lends  itself  to  manual  code 
analysis  to  determine  execution  time.  The  analysis  for  the  XD  Ada  runtime  system  clock  update 
is  included  in  Appendix  B  and  was  determined  take  15.4/js  to  update  the  clock  every  41,600/js. 
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3.5.2  Context  Switch  Time  Context  switch  time  is  the  time  required  to  save  the  state  of 
the  task  currently  executing  and  restoring  the  state  of  the  task  to  switch  to.  The  ACEC  provides  a 
measure  of  the  context  switch  time  and  determines  a  confidence  interval.  RATESIM  uses  the  worst 
case  execution  time  for  the  context  switch.  Further  details  of  the  context  switch  time  measurement 
can  be  found  in  Chapter  V. 

3.5.3  Rendezvous  Time  Rendezvous  time  is  the  time  required  for  two  tasks  to  synchronize 
their  execution  at  a  given  point  in  time.  The  ACEC  provides  several  measurements  of  rendezvous 
time.  It  measures  rendezvous  with  and  without  parameters,  rendezvous  when  the  calling  task  arrives 
first  and  when  the  called  task  arrives  first,  and  many  different  measurements  of  various  combinations 
of  selects  and  timed  entry  calls.  RATESIM  modeled  a  simple  rendezvous  (no  parameters,  or 
select  alternatives)  and  used  the  worst  case  execution  time  for  the  rendezvous  without  regard  to 
whether  the  calling  task  or  the  accepting  task  arrived  first.  Further  details  of  the  rendezvous  time 
measurement  can  be  found  in  Chapter  V. 

3.5.4  DELAY  Expiration  Time  An  Ada  DELAY  statement  introduces  a  significant  amount 
of  variability  into  the  runtime  behavior  of  a  task  set.  The  Ada  Language  Reference  Manual  (LRM) 
(5)  requires  only  that  the  DELAY  statement  provide  "...  at  least  the  duration  specified  ...”.  Ob¬ 
viously,  this  type  of  behavior  is  unacceptable  in  a  real-time  environment.  Therefore,  any  runtime 
system  designed  for  a  real-time  application  will  provide  a  DELAY  statement  that  is  more  pre¬ 
dictable  than  the  LRM  requires.  Since  the  DELAY  statement  is  dependent  on  the  timing  of  the 
runtime  environment  for  implementation  and  the  runtime  environment  is  unique  to  each  particu¬ 
lar  compilation  system,  the  behavior  of  the  DELAY  statement  is  not  predictable  between  various 
implementations. 

The  ACEC  will  measure  the  difference  between  the  delay  requested  by  a  program  and  the 
actual  delay  provided  by  the  runtime  system.  One  approach  to  modeling  the  DELAY  statement  is 
to  simply  add  the  worst  case  additional  delay  as  determined  by  the  ACEC  to  the  requested  delay. 
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The  ACEC  measurements  of  the  XD  Ada  DELAY  implementation  showed  that  the  additional  delay 
observed  could  vary  by  as  much  as  447 (is.  This  type  of  variability  will  result  in  poor  prediction  of 
schedulability  of  a  task  set  which  would  otherwise  be  schedulable. 

Based  on  the  ACEC  measurements,  a  model  of  the  DELAY  implementation  of  the  XD  Ada 
runtime  system  was  constructed.  This  model  accounted  for  143 (is  of  the  DELAY  statement  vari¬ 
ability.  An  additional  149/is  can  be  attributed  to  context  switching  leaving  155 ns  still  unaccounted 
for.  An  analysis  of  the  DELAY  implementation  of  the  XD  Ada  runtime  system  and  the  equation 
developed  to  model  it  can  be  found  in  Appendix  A. 

3. 6  Summary 

This  chapter  described  the  research  methodology  used  to  construct  and  validate  the 
RATESIM  model.  It  consisted  of  identifying  the  system  tasks  to  be  modeled  and  measuring  those 
tasks,  constructing  the  user  task  sets  and  repeatedly  comparing  the  behavior  of  a  given  user  task 
set  on  an  actual  machine  to  the  behavior  predicted  by  RATESIM.  These  comparisons  provided  the 
basis  for  refining  the  RATESIM  model  in  order  to  make  it  more  accurate. 

The  ACEC  was  the  method  used  to  determine  the  execution  times  of  the  identified  system 
tasks.  A  summary  of  the  ACEC  and  a  summary  of  the  analysis  of  the  collected  ACEC  data  was 
presented.  The  system  task  models  contained  within  RATESIM  was  a  direct  result  of  this  analysis. 

The  user  task  sets  used  for  validation  of  RATESIM  consisted  of  three  classes  of  tasks:  peri¬ 
odic/harmonic,  periodic/non-harmonic,  and  periodic/harmonic  with  synchronization.  The  test  bed 
used  during  this  research  consisted  of  a  Vaxstation  III  host  and  a  MC68020  single  board  computer 
serving  as  the  target  processor. 
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IV.  Model  Requirements,  Design,  and  Testing 


This  chapter  describes  the  purpose  and  objectives  of  the  RATESIM  model.  It  documents 
the  requirements  which  resulted  in  the  final  design  and  presents  the  environmental  and  behavioral 
models  of  RATESIM.  Finally,  the  test  plan  and  test  results  to  verify  the  operational  behavior  of 
RATESIM  is  presented. 

4-1  Purpose  and  Objectives 

The  purpose  of  RATESIM  is  to  model  an  embedded  runtime  system  that  will  “execute”  (i.e. 
account  for  the  CPU  utilization  of)  a  given  task  set  and  monitor  the  user  task  set  interaction  with 
the  runtime  system. 

The  primary  objective  of  the  RATESIM  model  is  to  determine  whether  a  user  task  set  can 
execute  on  a  real  processor  and  its  associated  runtime  system  without  missing  any  of  its  deadlines. 
This  determination  is  based  on  (1)  the  user  task  set,  (2)  the  execution  time  of  key  parameters  of  the 
runtime  system,  and  (3)  the  scheduling  strategy  of  the  runtime  system.  The  secondary  objective  is 
to  provide  insight  into  the  user  task  set  interaction  with  the  runtime  system.  This  insight  will  be 
provided  through  an  event  history  of  the  user  task  set’s  interaction  with  the  runtime  system  and 
statistics  based  on  that  interaction  such  as  CPU  time  allocated  to  user  tasks  and  user  deadlines 
missed. 

4.2  Motivation 

The  motivation  for  building  the  RATESIM  model  came  early  in  the  research  effort.  Initially, 
this  research  focused  on  constructing  a  general  mathematical  model  for  the  blocking  term  (B,)  in 
Section  2.1,  Equation  2.1,  Page  2-7.  This  equation  is  repeated  below: 

Vi,  1  <  i  <  n, min(^JI1i ci  A It^I  +  ft-  +  if*)  ^  1 

(k,l)€Ri 
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where  Cj  and  7)  are  the  execution  time  and  period  of  task  r;-  respectively,  Ri  =  {(t,  /)  |  1  <  Jt  <  i, 
1  =  1,  ■■■,  L^-J}  and  Bi  is  the  worst  case  blocking  time  for  t; 

The  objective  was  to  model  blocking  experienced  from  any  source:  the  runtime  system,  other 
user  tasks,  I/O,  etc. 

In  order  to  construct  such  an  equation,  detailed  data  had  to  be  gathered  on  the  blocking 
a  task  experiences  while  running  on  an  actual  processor.  In  order  to  gather  that  data  without 
introducing  timing  errors  into  the  measurements,  as  can  happen  when  using  software  to  gather 
such  information,  specialized  hardware  monitors  are  required.  Unfortunately,  that  hardware  was 
not  available. 

The  only  other  approach  available  was  to  use  a  software  based  method  to  gather  such  infor¬ 
mation.  The  System  Designers  XD  Ada  runtime  kernel  included  the  ability  to  record  the  execution 
path  while  executing  in  the  kernel,  but  there  is  a  three-fold  problem  associated  with  that:  (1)  no 
time  tags  were  attached  to  the  execution  trace,  (2)  even  if  there  were,  the  overhead  required  to 
generate  such  tags  might  be  sufficient  to  render  the  timing  information  useless,  and  (3)  the  data 
gathered  from  the  kernel  was  output  in  real-time  to  the  single  board  computer’s  serial  port,  thereby 
introducing  an  I/O  latency  that  certainly  rendered  the  data  useless. 

Consideration  was  given  to  overcoming  these  problems  by  adding  the  time  tag  information 
to  the  kernel  execution  trace  and  outputting  the  data  to  an  area  in  memory  for  read  out  after 
execution.  Of  course,  the  problem  of  ensuring  the  time  tag  did  not  introduce  excessive  overhead 
would  require  that  the  approach  be  validated  which,  in  turn,  would  require  the  specialized  hardware 
which  was  not  available  in  the  first  place. 

Another  difficulty  was  that  the  Hartstone  benchmark  provides  CPU  utilization  data  on  the 
user  task  set  only.  The  amount  of  unused  CPU  processing  capacity  that  is  system  overhead  and 
the  amount  that  is  CPU  idle  time  is  not  provided.  CPU  idle  time  could  be  determined  by  creating 
a  low  priority  user  task  which  would  run  only  when  the  CPU  wasn’t  performing  other  tasks. 
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This  task  would  record  the  amount  of  time  spent  within  it.  This  amount  of  time  would  be  the 
CPU  idle  time.  The  lack  of  this  data  meant  that  it  would  not  be  possible,  using  the  Hartstone, 
to  determine  what  portion  of  unused  CPU  capacity  was  system  overhead  and  use  that  data  to 
construct  the  mathematical  equation  for  blocking.  Data  on  system  utilization  of  the  CPU  would 
provide  additional  insight  into  a  processor’s  runtime  behavior  and  would  be  a  valuable  addition  to 
the  Hartstone  benchmark. 

Given  these  difficulties,  focus  shifted  to  constructing  a  parameterized  computational  model 
of  a  runtime  system.  Timing  data  for  the  individual  system  tasks  was  gathered  using  the  ACEC 
and  existing  documentation  for  the  particular  runtime  system.  The  Hartstone  benchmark  served 
to  validate  the  model,  since,  in  contrast  to  the  ACEC,  it  provides  timing  information  on  tasks  as 
they  execute  under  the  runtime  system.  Additionally,  since  the  computational  model  will  control 
the  system  clock,  an  event  trace  and  statistics  can  be  provided  without  introducing  any  timing 
errors  into  the  model.  The  event  trace  and  timing  statistics  provide  valuable  insight  into  user  task 
set  interaction  with  a  runtime  system. 

4-8  Model  Requirements 

The  requirements  for  the  RATESIM  model  provided  the  basis  for  the  final  design.  The  re¬ 
quirements  were  divided  into  three  types:  input  requirements,  functional  requirements,  and  output 
requirements.  These  requirements  are  itemized  below. 

4-8.1  Input  Requirements  The  RATESIM  model  must: 

1)  Have  the  ability  to  define  a  user  task  set  large  enough  to  represent  those  likely  to  be 

encountered  in  an  actual  system. 

2)  Accept  the  following  task  parameters: 

(a)  worst  case  execution  time, 
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(b)  period, 


(c)  deadline,  and 

(d)  synchronization  points. 

3)  Have  the  ability  to  specify  an  unlimited  number  of  system  tasks  along  with  their  asso¬ 
ciated  execution  time  and  frequency. 

4.3.2  Functional  Requirements  The  model  must: 

1)  Provide  a  1  fxs  simulation  time  resolution. 

2)  Use  a  preemptive,  event-driven,  fixed  priority  scheduling  algorithm, 

3)  Support  the  following  tasking  constructs:  (a)  task  suspension,  and  (b)  task  synchro¬ 
nization. 

4)  Provide  the  following  runtime  system  functions:  (a)  context  switch,  and  (b)  system 
clock  update. 

5)  Assign  priorities  according  to  the  rate  monotonic  priority  assignment  scheme. 

6)  Make  a  conservative  determination  of  user  task  set  schedulability  (i.e.  does  not  report 
a  task  set  can  successfully  meet  all  its  deadlines  when  in  fact  it  cannot). 

4-3.3  Output  Requirements  The  model  must: 

1)  Provide  a  time  ordered  history  of  runtime  events, 

2)  Provide  the  following  statistics  on  each  user  task: 

(a)  cumulative  execution  time, 

(b)  number  of  deadlines  met, 

(c)  number  of  deadlines  missed, 
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(d)  time  of  first  deadline  missed 


(e)  for  the  first  deadline  missed,  the  time  execution  associated  with  that  deadline 
was  finally  completed, 

(f)  cumulative  time  of  late  deadlines, 

(g)  number  of  preemptions  suffered  due  other  tasks, 

(h)  cumulative  time  of  early  deadlines, 

(i)  number  of  context  switches, 

(j)  and  number  of  delay  expirations. 

3)  Provide  the  following  statistics  for  each  simulation  run: 

(a)  simulation  time, 

(b)  user  cumulative  task  execution  time, 

(c)  user  deadlines  met, 

(d)  user  deadlines  missed, 

(e)  context  switches, 

(f)  delay  expirations, 

(g)  system  task  execution  time, 

(h)  idle  time, 

(i)  percentage  user  task  execution  time, 

(j)  percentage  system  task  execution, 

(k)  percentage  idle  time, 

(l)  cumulative  induced  priority  inversion  time  due  to  DELAY  statement  jitter. 
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4-8.4  RATESIM  Specification  Specifications  for  RATESIM  are  contained  in  Table  4.1. 


The  context  diagram  shown  in  Figure  4.1  illustrates  how  RATESIM  interacts  with  the  outside 
world.  RATESIM  requires  the  user  to: 

1)  specify  the  user  task  set  either  by  supplying  the  file  where  the  task  set  is  stored  (File¬ 
name)  or  entering  the  task  set  interactively  (Task  Parameters), 

2)  specify  the  file  where  a  task  set  is  to  be  saved  to  (Filename), 

3)  and  provide  the  length  of  time  to  run  the  simulation  (Simulation  Time). 

4-8.5  Environmental  Model  This  section  describes  the  environment  in  which  the  RATESIM 
model  exists.  It  specifies  the  purpose  of  RATESIM,  the  input  data  it  requires,  and  the  output  data 
it  provides. 

The  following  list  is  a  comprehensive  list  of  user  inputs  which  RATESIM  will  respond  to. 

1)  add  a  task, 

2)  delete  a  task, 

3)  edit  a  task, 

4)  run  simulation, 

5)  rate  monotonic  equation, 

6)  display  task  set, 

7)  get  task  set  from  a  file, 

8)  save  task  set  to  a  file, 

9)  and  invalid  input. 
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All  of  the  above  inputs  are  self-explanatory  except  rate  monotonic  equation.  That  causes 
RATESIM  to  determine  whether  or  not  the  task  set  is  schedulable  based  on  Equation  2.1,  on 
Page  2-7  (repeated  below). 

Vi,  1  <  i  <  n,  mm(£‘ _  \  Cj  jjr-  +  ]§£  +  H\)  <  1 

(kJ)ERi 

where  C,  and  7}  are  the  execution  time  and  period  of  task  Tj  respectively,  /£,  =  {(Jb,  /)  |  1  <  k  <  i, 
/  =  1,  . . .,  and  B{  is  the  worst  case  blocking  time  for  tj. 

Its  purpose  is  to  provide  a  confidence  check  of  the  simulation  results.  The  simulation  results 
and  the  calculated  inequality  should  agree. 

RATESIM  provides  to  the  user: 

1)  the  result  of  the  rate  monotonic  equation  (Rate  Monotonic  Equation), 

2)  a  chronological  list  of  simulation  events  (Event  History), 

3)  and  the  statistics  gathered  during  the  course  of  the  simulation  (Statistics). 

4-4  RATESIM  Design 

This  section  describes  the  internal  behavior  of  the  RATESIM  model.  Eight  entities  are  used 
within  RATESIM  and  Figure  4.2  illustrates  the  relationships  between  them. 

1.  System  Statistics  is  a  data  structure  that  bolds  all  the  system-wide  statistical  data 
collected  during  a  given  RATESIM  simulation.  It  has  no  explicit  relationship  with  any 
other  entity. 

2.  Ready  Queue  is  a  prioritized  queue  (based  on  the  task  period)  of  User  Tasks.  Ready 
Queue  is  used  during  the  execution  of  RATESIM  to  hold  any  User  Task  which  is  ready 
to  execute  but  has  not  yet  been  granted  access  to  the  simulation  “CPU” . 
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3.  System  Queue  is  a  prioritized  queue  (based  on  execution  start  time)  of  System  Tasks. 
System  Queue  is  used  during  the  execution  of  RATESIM  to  hold  any  System  Task  which 
is  ready  to  execute  but  whose  execution  time  has  not  yet  arrived. 

4.  System  Task  contains  the  parameters  associated  with  a  particular  system  task.  Exam¬ 
ples  of  the  task  parameters  include  task  type  and  execution  time.  Note  that  a  System 
Task  may  be  implicitly  defined  within  RATESIM  such  as  a  context  switch  or  system 
clock  update,  or  a  System  Task  may  be  initiated  by  a  User  Task  requesting  a  system  ser¬ 
vice  such  as  task  suspension  (or  DELAY),  or  an  Ada  rendezvous  (ACCEPT  or  ENTRY 
CALL).  System  tasks,  in  this  version  of  RATESIM,  Me  manually  added  by  modifying 
the  RATESIM  source  code. 

5.  Rendezvous  Queue  is  a  prioritized  queue  (based  on  arrival  time)  of  ACCEPT  or  ENTRY 
System  Tasks.  Rendezvous  Queue  is  used  to  hold  an  ACCEPT  or  ENTRY  System  Task 
executed  on  behalf  of  the  User  Task  that  made  the  call,  but  which  has  not  yet  received 
the  corresponding  ACCEPT  or  ENTRY  call. 

6.  User  Task  contains  all  the  parameters  associated  with  a  particular  user-specified  task. 
Examples  of  task  parameters  include  period,  execution  time,  and  deadline.  As  seen  in 
Figure  4.2  there  is  a  one-to-one  correspondence  between  an  instance  of  User  Task  and 
an  instance  of  User  Statistics. 

7.  User  Statistics  is  a  data  structure  that  holds  all  the  statistical  data  collected  during  a 
given  RATESIM  simulation  for  a  given  User  Task. 

8.  Rendezvous  Ring  is  a  prioritized  ring  (based  on  execution  start  time)  of  task  synchro¬ 
nization  events  (an  entry  call  or  accept).  After  the  execution  of  a  call  or  accept  the  ring 
is  rotated  to  point  to  the  next  synchronization  event.  After  execution  is  complete  for 
the  given  user  task  period,  the  ring  is  reset  to  point  to  the  first  synchronization  event 
of  the  period 
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4-4-1  RATESIM  Transaction  Diagram  and  Data  Flow  Model  The  transaction  diagram  in 
Figure  4.3  shows  the  transactions  that  occur  at  the  user  interface  level  of  RATESIM.  Most  of  the 
RATESIM  functions  depend  on  the  Task  Parameters  (supplied  by  the  user)  which  are  used  to 
construct  User  Tasks  and  are  then  placed  in  the  data  store  Task  List.  An  external  data  store  (e.g. 
a  file)  Tasks  is  used  to  store  User  Tasks  between  executions  of  RATESIM. 

Figure  4.4  shows  the  data  flow  during  the  simulation.  First,  all  User  Tasks  are  placed  in 
the  store  Ready  Queue  and  the  Simulation  Run  Flag  is  set  to  true.  Placing  all  User  Tasks  on  the 
Ready  Queue  establishes  the  worst  case  phasing  of  the  user  task  set.  Initial  (or  implicit)  System 
Tasks  such  as  a  system  clock  update  are  read  from  the  System  Task  store  and  placed  in  the  store 
System  Queue.  System  Tasks  are  also  placed  on  System  Queue  during  the  simulation  depending 
on  what  system  services  (e.g.  task  suspension,  synchronization)  are  requested  by  a  User  Task. 
The  Simulation  Time  is  obtained  from  the  user  and  simulation  begins.  During  the  course  of  the 
simulation  user  task  statistics  are  updated  and  placed  in  the  User  Statistics  store,  the  Event  History 
is  produced,  system  statistics  are  saved  in  the  System  Statistics  store,  and  the  System  Queue  and 
Ready  Queue  have  user  and  system  tasks  added  and  removed  as  required. 

For  the  Rate  Monotonic  Equation  process,  tasks  are  input  from  the  User  Task  store  (see  Fig¬ 
ure  4.5)  and  if  the  Simulation  Run  Flag  is  true,  blocking  information  is  read  from  the  User  Statistics. 
Schedulable  is  set  to  true  or  false  based  on  the  result  of  the  Rate  Monotonic  Equation. 

Figure  4.6  shows  the  Do  Simulation  process  at  a  more  detailed  level  during  the  simulation. 
Execute  System  Task  takes  a  system  task  from  the  front  of  the  System  Queue  and  updates  Sys¬ 
tem  Statistics,  outputs  an  event  (Event  History)  and  may  (depending  on  the  system  task)  place 
a  User  Task  on  the  Ready  Queue.  Similarly,  Execute  User  Task  takes  a  user  task  from  the  front 
of  the  Ready  Queue  and  may  (depending  on  the  the  user  task)  take  a  system  task  from  the  Ren¬ 
dezvous  Queue.  It  then  updates  User  Task  Statistics/System  Statistics,  records  an  event  (Event  His¬ 
tory)  and  may  (again  depending  on  the  user  task)  place  a  System  Task  on  the  System  Queue  or 
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back  on  the  Rendezvous  Queue.  Calculate  Statistics  occurs  at  the  end  of  the  simulation  and  it 
simply  gathers  the  user  task  and  system  statistics  generated  during  the  simulation  and  outputs 
them  to  the  user. 

4-4-2  Flow  Charts  Much  of  the  control  flow  in  RATESIM  occurs  at  the  user  interface  level 
and  is  largely  routine  and  uninteresting.  Therefore,  the  following  section  will  presents  details  about 
the  Do  System  Task,  Do  User  Task,  and  Do  Idle  processes  within  RATESIM.  These  processes  are 
explained  further  in  the  sections  below. 

4-4-2. 1  Do  System  Task  RATESIM  operates  in  the  process  Do  System  Task  while 
there  is  a  system  task  which  has  a  start  time  less  than  or  equal  to  the  current  simulation  time. 
Two  data  structures  define  this  state,  System  Task  Queue  and  Time.  System  Task  Queue  is  a 
prioritized  queue  of  System  Tasks  with  the  start  time  of  the  task  determining  the  priority.  Time  is 
simply  an  integer  which  contains  the  elapsed  simulation  time  in  microseconds. 

When  RATESIM  begins,  there  is  only  one  system  task  on  System  Task  Queue,  Clock  Update. 
This  system  task  is  the  only  task  that  will  execute  independent  of  a  user  task  requesting  a  system 
service.  The  other  system  tasks,  Context  Switch,  Delay,  Rendezvous  Call,  and  Rendezvous  Accept, 
are  only  initiated  upon  a  user  task  request  for  the  service  and  are  explained  below  (see  Figure  4.7). 

1.  Clock  Update:  When  a  Clock  Update  is  executed,  the  following  things  occur: 

(a)  the  task  is  removed  from  the  System  Task  Queue, 

(b)  the  clock  update  event  is  recorded, 

(c)  since  this  is  a  periodic  system  task,  the  next  Clock  Update  execution  is  added 
to  the  System  Task  Queue, 

(d)  and  finally  Clock  Update  is  “executed”  by  adding  the  Clock  Update  execution 
time  to  Time. 
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2.  Context  Switch:  During  a  Context  Switch,  Do  System  Task  performs  the  following 
actions: 

(a)  the  context  switch  event  is  recorded, 

(b)  and  Context  Switch  is  “executed”  by  adding  the  Context  Switch  execution 
time  to  Time. 

A  context  switch  can  be  modeled  in  many  ways.  One  method  of  modeling  it  is  to  add 
twice  the  context  switch  execution  time  (once  for  switching  into,  then  out  of  the  user 
task)  to  the  task  execution  time  (8).  Therefore,  it  becomes  indistinguishable  from  the 
user  task  execution  time.  Another  way  to  model  it  is  as  a  system  task  that  is  executed 
each  time  the  task  begins  execution.  The  distinction  is  that  when  the  context  switch  is 
simply  added  to  the  user  execution  time,  accounting  for  the  time  spent  doing  context 
switches  is  no  longer  possible.  Therefore,  RATESIM  models  a  context  switch  as  a 
system  task  that  is  executed  each  time  the  task  begins  execution.  This  design  decision 
permitted  cleaner  design  since  it  clearly  separated  what  was  user  task  utilization  of  the 
CPU  and  what  was  overhead  (i.e.  a  system  task). 

A  by-product  of  this  design  decision  is  that  the  Context  Switch  task  does  not  involve 
removing  a  task  from  the  System  Task  Queue.  That  is,  rather  than  a  scheduled  system 
task  execution,  a  user  task  requests  the  context  switch  when  it  begins  its  execution  and 
the  system  service  is  immediately  performed. 

A  Delay  is  the  result  of  a  User  Task  requesting  suspension.  The  User  Task  that  requested 
the  suspension  is  saved  by  the  Delay  system  task  so  that  when  the  system  task  is 
executed,  the  User  Task  requesting  the  suspension  can  be  rescheduled. 

3.  Delay:  When  a  Delay  is  executed,  the  following  things  occur: 

(a)  the  user  task  requesting  the  suspension  is  rescheduled  on  the  Ready  Queue, 
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(b)  the  Delay  task  is  removed  from  the  System  Task  Queue, 

(c)  the  delay  event  is  recorded, 

(d)  Delay  is  “executed”  by  adding  the  Delay  execution  time  to  Time, 

(e)  if,  after  updating  Time,  any  other  Delays  on  System  Queue  have  execution 
start  times  less  than  or  equal  to  Time,  they  are  also  executed  but  at  a  signif¬ 
icantly  smaller  execution  time  penalty. 

This  is  an  assumed  optimization  generally  implemented  in  most  runtime  systems.  That 
is,  if  some  other  task’s  delay  will  expire  within  the  amount  of  time  it  takes  to  “wake 
up”  a  previous  task’s  delay  expiration,  the  other  task  will  be  rescheduled  at  a  reduced 
penalty.  In  the  case  of  the  XD  Ada  runtime  environment,  the  reduced  penalty  was  4  ps. 

4.  Rendezvous  Call:  A  Rendezvous  Call  is  executed  when  a  User  Task  (the  calling  task) 
requests  synchronization  with  another  task  (the  accepting  task).  A  single  ASCII  char¬ 
acter  is  used  to  identify  the  Accept  entry  the  calling  task  wants  to  synchronize  with. 
Timed  calls  are  not  supported.  That  is,  if  a  corresponding  Accept  (from  the  accepting 
task)  is  not  executed,  the  calling  task  will  be  suspended  forever.  Although  it  is  a  system 
task,  a  Rendezvous  Call  will  never  be  found  on  the  System  Task  Queue.  It  is  held  on 
the  Rendezvous  Queue  until  the  corresponding  Accept  is  executed. 

5.  Rendezvous  Accept:  A  Rendezvous  Accept  is  executed  when  a  User  Task  (the  accepting 
task)  has  accepted  synchronization  from  the  calling  task.  Note  that  until  both  the 
Rendezvous  Call  and  the  corresponding  Rendezvous  Accept  have  been  executed,  the 
Call  or  Accept  will  reside  in  the  Rendezvous  Queue.  After  both  have  been  executed, 
a  Rendezvous  Accept  system  task  will  be  placed  on  the  System  Task  Queue.  Upon 
executing  a  Rendezvous  Accept  the  following  will  occur: 
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(a)  the  accepting  task’s  priority  will  be  changed  to  the  higher  of  its  own  priority 
or  the  calling  task  priority, 

(b)  the  accepting  task  will  be  rescheduled, 

(c)  the  Rendezvous  Accept  task  is  removed  from  the  System  Task  Queue, 

(d)  the  rendezvous  event  is  recorded, 

(e)  and  Rendezvous  Accept  is  “executed”  by  adding  the  Rendezvous  Accept  ex¬ 
ecution  time  to  Time. 

RATESIM  enters  Do  User  Task  when  the  next  system  task  to  execute  has  a  start  time  greater 
than  Time.  Two  data  structures  define  Do  User  Task  ,  Ready  Queue  and  Time.  Time  is  the  same 
data  structure  as  described  in  the  previous  section.  Ready  Queue  is  a  prioritized  queue  of  User  Tasks 
with  priorities  assigned  according  to  RMA. 

When  Do  User  Task  begins,  there  are  zero  or  more  User  Task’s  on  the  queue.  There  may 
be  zero  tasks  on  the  queue  for  one  of  two  reasons:  (1)  no  user  tasks  were  defined,  or  (2)  all  user 
tasks  that  were  defined  have  requested  a  system  service  and  are  either  on  System  Task  Queue  or 
Rendezvous  Queue.  If  there  are  zero  User  Task’s  on  the  queue  RATESIM  enters  the  Do  Idle  state 
(described  below)  until  such  time  as  the  next  System  Task  is  executed. 

In  Do  User  Task,  the  following  sequence  of  events  occur  (see  Figures  4.8  and  4.9): 

1)  CHECK  NEXT  USER  TASK  (1):  if  Next  System  Task  Start  =  TIME  or  Ready  Queue 
is  empty  then  no  User  Task  is  executed. 

2)  DO  CONTEXT  SWITCH  (2):  a  Context  Switch  system  task  is  executed  unless  this 
User  Task  is  being  executed  twice  in  a  row  without  a  different  User  Task  or  System  Task 
being  executed  in  between. 

This  situation  could  occur  immediately  after  task  synchronization  when  both  tasks 
that  were  in  rendezvous  are  rescheduled.  The  accepting  task  (which  was  executing) 


4-13 


might  still  be  the  highest  priority  User  Task  and  begin  execution  again.  In  this 
situation,  no  Context  Switch  system  task  is  initiated. 

3)  BEGIN  EXECUTION  (3):  the  time  available  for  the  User  Task  execution  is  determined 
(the  next  system  task  start  time  minus  the  current  time). 

4)  the  User  Task  is  removed  from  the  Ready  Queue. 

5)  a  User  Task  Execution  Begin  event  is  recorded. 

6)  ADJUST  AVAILABLE  TIME  (4):  if  the  User  Task  is  in  the  middle  of  an  Accept 
execution,  the  time  available  for  User  Task  execution  is  adjusted  to  be  the  smaller  of 
the  current  available  time  (as  determined  in  item  ii  above)  or  the  Accept  execution 
time. 

7)  EXECUTE  TASK  (5):  the  User  Task  is  “executed”. 

User  Task  execution  contains  many  substates  which  are  described  in  Section  4.4.2.2. 

8)  EXECUTION  END  (6):  a  User  Task  Execution  Stop  event  is  recorded. 

9)  REQUEST  DELAY  (7):  if  the  User  Task  has  completed  its  execution  time  for  this 
period,  a  Deadline  Met  or  a  Deadline  missed  event  is  recorded  and  the  User  Task 
initiates  a  task  suspension  system  task  (Delay). 

10)  RESCHEDULE  (9):  if  the  User  Task  has  not  completed  its  execution  time  for  this 
period,  it  is  rescheduled. 

11)  SEARCH  FOR  ENTRY  OR  ACCEPT  (8):  if  the  User  Task  has  executed  a  Ren¬ 
dezvous  Entry  or  Rendezvous  Accept  the  Rendezvous  Queue  is  searched  for  a  corre¬ 
sponding  entry  or  accept,  and  a  Rendezvous  Event  is  recorded. 

CREATE  RENDEZVOUS  SYSTEM  TASK  (10):  if  the  corresponding  entry  is 
found,  the  User  Task  initiates  a  Rendezvous  Accept  system  task. 
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PLACE  ON  RENDEZVOUS  QUEUE  (11):  if  not  found,  the  User  Task  is  placed 
on  the  Rendezvous  Queue  to  await  the  corresponding  entry  or  accept. 

12)  UPDATE  NEXT  SYSTEM  TASK  START  (12):  finally,  since  User  Task’s  can  initiate 
a  system  task  which  may  have  a  start  time  earlier  than  the  current  next  system  task 
start  time,  the  next  system  task  start  time  is  updated. 

4- 4. ■?- 2  Execute  User  Task  The  Execute  User  Task  state  (see  Figure  4.10)  is  part  of 
the  Do  User  Task  state.  Due  to  the  many  substates  within  Execute  Task,  it  is  described  in  detail 
in  this  section. 

When  Execute  User  Task  begins,  the  following  information  is  passed  to  it:  (1)  Available  Time 
(for  task  execution)  and  (2)  The  Task  (the  task  to  execute).  The  following  sequence  of  events  then 
occurs  (see  Figure  4.10): 

1)  CHECK  AVAILABLE  TIME  (5.1):  it  is  determined  whether  a  rendezvous  (entry  call 
or  accept)  will  occur  during  this  execution. 

2)  Available  Time  is  checked  to  determine:  (a)  if  it  is  zero  or  less,  (b)  whether  The  Task 
can  complete  its  execution  within  Available  Time. 

Available  Time  could  be  zero  or  less  if  the  Context  Switch  execution  time  used  up 
all  the  execution  time  budget.  If  so,  no  execution  time  is  allotted  to  The  Task. 

If  The  Task  will  complete  its  execution  within  Available  Time,  an  execution  com¬ 
plete  flag  is  set. 

3)  ALLOCATE  EXECUTION  TIME  (5.2):  if  a  rendezvous  will  occur  during  this  execution 
time,  sufficient  execution  time  is  allocated  to  The  Task  to  reach  the  rendezvous  point, 
otherwise  up  to  Available  Time  execution  time  is  allocated  to  The  Task. 
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4)  ALLOCATE  ACCEPT  TIME  (5.3):  if  The  Task  is  in  the  process  of  executing  an  Accept 
(it  was  already  in  rendezvous  when  execution  began),  then  execution  time  is  allocated 
to  the  Accept  execution  time. 

5)  RECORD  STOP  ACCEPT  (5.4):  if  the  Accept  has  been  allocated  sufficient  execution 
time  to  finish,  a  Stop  Accept  event  is  recorded  and  the  task  that  placed  the  entry  call 
is  rescheduled. 

6)  RECORD  EXECUTION  STOP  (5.5):  a  User  Task  Execution  Stop  event  is  recorded. 

7)  RECORD  EXECUTION  TIME  REQUIRED  (5.6):  and  finally  an  Additional  User  Task 
Execution  Time  Required  event  is  recorded. 

4-4-2-S  Do  Idle  When  Time  is  less  than  the  next  system  task  start  time  and  there  are 
no  User  Tasks  to  execute,  RATESIM  transitions  to  Do  Idle  and  an  Idle  event  is  recorded.  Do  Idle 
is  terminated  when  the  next  system  task  start  time  is  equal  to  Time. 

4.5  Testing 

This  section  addresses  the  testing  RATESIM  underwent  to  ensure  proper  operation.  Con¬ 
trasted  with  validation  (discussed  in  the  next  chapter)  which  attempts  to  ensure  that  the  RATESIM 
model  design  accurately  simulates  an  embedded  runtime  system,  testing  ensures  the  proper  opera¬ 
tion  of  the  RATESIM  program  . 

The  objective  in  testing  RATESIM  was  to  give  a  reasonable  assurance  that  the  program  would 
not  abort  execution  abnormally  due  to  invalid  user  input  or  lack  of  operating  system  memory. 
Additionally,  to  the  extent  that  data  integrity  checks  were  performed  by  RATESIM,  the  objective 
was  to  ensure  that  those  checks  operate  correctly. 

The  data  integrity  checks  performed  by  RATESIM  to  ensure  user  entered  data  is  of  the  proper 
form  does  not  include  all  checks  necessary  to  ensure  the  integrity  of  the  user  task  parameters  input 


4-16 


to  RATESIM.  For  instance,  when  inputing  rendezvous  events,  RATESIM  depends  on  the  user  to 
input  them  sequentially  from  the  earliest  start  time  to  the  latest.  If  the  user  does  not,  the  result 
will  be  unpredictable.  The  additional  data  integrity  checks  that  need  to  be  added  to  the  RATESIM 
program  are  listed  in  Table  4.3. 


4-5.1  Test  Cases  This  section  enumerates  the  test  cases  that  were  used  to  test  RATESIM 
and  the  results  of  those  tests.  Data  integrity  tests  that  ensure  proper  operation  of  RATESIM  but 
currently  rely  on  proper  user  input  are  listed,  but  the  test  results  are  marked  N/I  (not  implemented). 

Three  classes  of  test  were  performed:  (1)  user  input,  (2)  data  integrity,  and  (3)  stress  tests. 
User  input  tests  will  ensure  that  no  user  input  will  cause  the  program  to  abort  abnormally.  Data 
integrity  tests  will  ensure  that  the  data  input  is  in  a  form  that  RATESIM  is  expecting.  Stress  tests 
will  ensure  that  RATESIM  will  perform  as  designed  at  the  limits  of  its  specifications. 


4-5.2  Event  History  Example  The  following  is  an  sample  of  the  output  of  RATESIM ’s  event 
history.  System  Tasks  events  are  in  uppercase  for  easier  identification.  Table  4.5  lists  all  the  events 
recorded  by  RATESIM  and  the  information  reported  when  those  events  occur  such  as  start  time, 
stop  time,  and  execution  time. 


2)  started  executing  at 
2)  stopped  executing  at 
2992  us. 

2)  still  requires 
2)  met  its  deadline  of 
It  mas  11192  us  early. 

User  Task  Task  4(PID  2)  requested  a  DELAY  of 
Actual  DELAY  sill  be  :  11213  us. 


User  Task  Task  4(PID 
User  Task  Task  4(PID 
Execution  tine  : 
User  Task  Task  4(PID 
User  Task  Task  4(PID 


6385952. 

6388944. 

0  us  of  execution  time. 
6400136  at  6388944. 

11192  us. 


SYSTEH.TASK  COITEXT.SHITCH  FROM  6388944  TO  6389093. 
EXECUTIOV  TINE  :  149  US. 


User  Task  Task  2(PID 
User  Task  Task  2(PID 
Execution  time  : 
User  Task  Task  2(PID 
SYSTEN.TASK  A.DELAY 


4)  started  executing  at 
4)  stopped  executing  at 
3048  us. 

4)  still  requires 

FROM  6392141  TO 


6389093. 

6392141 . 

5817  us  of  execution  time. 
6392300. 
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EXECUTIOI  TIME  :  159  US. 

DELAY  EXPIRATIOI  OF  Task  5(PID  1) . 

SYSTEM_TASK  COITEXT.SHITCH  FROM  6392300  TO  6392449. 

EXECUTIOI  TIME  :  149  US. 

User  Task  Task  5(PID  1)  started  executing  at 
User  Task  Task  5(PID  1)  stopped  executing  at 
Execution  time  :  1496  us. 

User  Task  Task  5(PID  1)  still  requires 
User  Task  Task  5(PID  1)  met  its  deadline  of 
It  vas  6191  us  early. 

User  Task  Task  5(PID  1)  requested  a  DELAY  o 1  : 

Actual  DELAY  will  be  :  6175  us. 

SYSTEM.TASK  COITEXT.SHITCH  FROM  6393945  TO  6394094. 

EXECUTIOI  TIME  :  149  US. 

User  Task  Task  2(PID  4)  started  executing  at 
User  Task  Task  2(PID  4)  stopped  executing  at 
Execution  time  :  5817  us. 

User  Task  Task  2(PID  4)  still  requires 
User  Task  Task  2(PID  4)  met  its  deadline  of 
It  was  32713  us  early. 

User  Task  Task  2(PID  4)  requested  a  DELAY  of  : 

Actual  DELAY  mill  be  :  32825  us. 

SYSTEM.TASK  COITEXT.SHITCH  FROM  6399911  TO  6400060. 

EXECUTIOI  TIME  :  149  US. 

User  Task  Task  1(PID  5)  started  executing  at 

User  Task  Task  1(PID  5)  stopped  executing  at 

Execution  time  :  60  us. 

User  Task  Task  1(PID  5)  still  requires 
SYSTEM.TASK  A.DELAY  FROM  6400120  TO 

EXECUTIOI  TIME  :  159  US. 

DELAY  EXPIRATIOI  OF  Task  5(PID  1) . 

SYSTEM.TASK  A.DELAY  FROM  6400279  TO 

EXECUTIOI  TIME  :  4  US. 

DELAY  EXPIRATIOI  OF  Task  4(PID  2) . 

SYSTEM.TASK  A.DELAY  FROM  6400283  TO 

EXECUTIOI  TIME  :  4  US. 

DELAY  EXPIRATIOI  OF  Task  3(PID  3) . 

SYSTEM.TASK  COITEXT.SHITCH  FROM  6400287  TO 

EXECUTIOI  TIME  :  149  US. 

User  Task  Task  5(PID  1)  started  executing  at  6400436. 

User  Task  Task  5(PID  1)  stopped  executing  at  6401932. 

Execution  time  :  1496  us. 

User  Task  Task  5(PID  1)  still  requires  0  us  of  execution  time. 

User  Task  Task  5(PID  1)  net  its  deadline  of  6408258  at  6401932. 

It  «as  6326  us  early. 


6400060. 

6400120. 

23878  us  of  execution  time. 
6400279. 

6400283. 

6400287. 

6400436. 


6394094. 

6399911. 

0  us  of  execution  time. 
6432624  at  6399911. 

32713  us. 


639244C . 

6393945. 

0  us  of  execution  time. 
6400136  at  6393945. 

6191  us. 


U8«r  Task  Task  5(PID  1)  requested  a  DELAY  of  :  6326  us. 

Actual  DELAY  sill  be  :  6500  us. 

SYSTEM.TASK  COITEXT.SVITCH  FROM  6401932  TO  6402081. 

EXECUTIOI  TINE  :  149  US. 

User  Task  Task  4(PID  2)  started  executing  at  6402081. 

User  Task  Task  4(PID  2)  stopped  executing  at  6405073. 

Execution  tine  :  2992  us. 

User  Task  Task  4(PXD  2)  still  requires  0  us  of  execution  tine. 

User  Task  Task  4(PXD  2)  net  its  deadline  of  6416380  at  6405073. 

Xt  sas  11307  us  early. 

User  Task  Task  4(PID  2)  requested  a  DELAY  of  :  11307  us. 

Actual  DELAY  sill  be  :  11375  us. 

SYSTEM.TASK  COITEXT.SVITCH  FROM  6405073  TO  6405222. 

EXECUTIOI  TIME  :  149  US. 

User  Task  Task  3(PID  3)  started  executing  at  6405222. 

User  Task  Task  3(PID  3)  stopped  executing  at  6406400. 

Execution  tine  :  1178  us. 

User  Task  Task  3(PID  3)  still  requires  4806  us  of  execution  tine. 

SYSTEM.TASK  CL0CK.UPDATE  FROM  6406400  TO  6406415. 

EXECUTIOI  TIME  :  15  US. 

SYSTEM.TASK  COITEXT.SVITCH  FROM  6406415  TO  6406564. 

EXECUTIOI  TIME  :  149  US. 

User  Task  Task  3(PID  3)  started  executing  at  6406564. 

User  Task  Task  3(PID  3)  stopped  executing  at  6408432. 

Execution  tine  :  1868  us. 

User  Task  Task  3(PID  3)  still  requires  2938  us  of  execution  tine. 

SYSTEM.TASK  A.DELAY  FROM  6408432  TO  6408591. 

EXECUTIOI  TIME  :  159  US. 

DELAY  EXPIRATIOI  OF  Task  5(PID  1). 

SYSTEM.TASK  COITEXT.SVITCH  FROM  6408591  TO  6408740. 

EXECUTIOI  TIME  :  149  US. 

User  Task  Task  5(PID  1)  started  executing  at  6408740. 

User  Task  Task  5(PID  1)  stopped  executing  at  6410236. 

Execution  tine  :  1496  us. 

User  Task  Task  5(PID  1)  still  requires  0  us  of  execution  tine. 

User  Task  Task  5(PID  1)  net  its  deadline  of  6416380  at  6410236. 

It  was  6144  us  early. 

User  Task  Task  5(PID  1)  requested  a  DELAY  of  :  6144  us. 

Actual  DELAY  will  be  :  6175  us. 

SYSTEM.TASK  COITEXT.SVITCH  FROM  6410236  TO  6410385. 

EXECUTIOI  TIME  :  149  US. 

User  Task  Task  3(PID  3)  started  executing  at  6410385. 

User  Task  Task  3(PXD  3)  stopped  executing  at  6413323. 
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Execution  tine  :  2938  us. 

User  Task  Task  3(PID  3)  still  requires  0  us  of  execution  time. 

User  Task  Task  3(PID  3)  met  its  deadline  of  6432624  at  6413323. 

It  mas  19301  us  early. 

User  Task  Task  3(PID  3)  requested  a  DELAY  of  :  19301  us. 

Actual  DELAY  mill  be  :  19338  us. 


SYSTEMJTASK  COITEXT.SHITCH  FROM  6413323  TO  6413472. 
EXECUTX01  TIME  :  149  US. 


User  Task  Task  1(PID 
User  Task  Task  1(PID 
Execution  time  : 
User  Task  Task  1(PID 


5)  started  executing  at 
5)  stopped  executing  at 
2939  us. 

S)  still  requires 


6413472. 

6416411. 

20939  us  of  execution  time. 


4-6  Summary 

The  need  for  specialized  measurement  hardware  or  expensive  simulator  development  to  char¬ 
acterize  a  single  runtime  environment  motivated  the  development  of  a  software-based,  parame¬ 
terized  model  that  could  simulate  various  runtime  environments.  The  purpose  of  the  RATESIM 
model  is  to  simulate  an  embedded  runtime  system  that  will  execute  a  given  task  set  and  monitor 
the  user  task  set  interaction  with  the  runtime  system.  The  RATESIM  model  has  two  objectives: 
(1)  to  determine  whether  a  user  task  set  can  execute  on  a  read  processor  with  its  associated  run¬ 
time  system  without  missing  any  of  its  deadlines,  and  (2)  to  provide  insight  into  the  user  task  set 
interaction  with  that  runtime  system.  This  chapter  also  presented  the  requirements  and  design  of 
the  RATESIM  program.  In  addition,  the  testing  RATESIM  underwent  was  discussed. 
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Table  4.1.  RATESIM  Specification 


Item 

Range 

User  Tasks 

System  Tasks 

Simulation  Time  (in  /is) 

Synchronization  Events  (Entry  Call  or  Accepts) 
Synchronization  Point  Names 

0  to  99 
no  limit 

0  to  2,100,000,000  (0  to  35  minutes) 

0  to  20  per  user  task 
single  alpha-numeric  character 

Figure  4.1.  RATESIM  Context  Diagram 


Table  4.2.  Test  Cases  -  User  Input 


Test 

Objective 

Result 

Main  Menu/Valid  Input 

accept  valid  menu  choice 

pass 

Main  Menu/Invalid  Input 

reject  invalid  menu  choice 

pass 

Numeric  Input/Valid  Input 

accept  valid  numeric  input 

pass 

Numeric  Input/Invalid  Input 

reject  invalid  or  out  of  range  numeric  input 

pass 

Text  Input/ Valid  Input 

accept  valid  text 

pass 

Text  Input/Invalid  Input 

reject  strings  which  are  too  long 

pass 
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Figure  4.2.  RATESIM  Entity  Relationships 


Table  4.3.  Test  Cases  -  Data  Integrit’ 


Test  |  Objective  Result 


User  Task  Period  ensure  period  >  execution  time  pass 

User  Task  Deadline  ensure  deadline  >  execution  time  and  <  period  pass 

Rendezvous  Order  rendezvous  points  sequential  from  earliest  to  latest  N/I 

Rendezvous  Start  0  <  start  time  <  execution  time  N/I 

Rendezvous  Points  rendezvous  events  do  not  overlap  N /I 

Accept  Execution  Time  -  1  ensure  accept  execution  time  +  accept  start  time  N /I 

<  execution  time 

Accept  Execution  Time  -  2  accept  execution  time  >0  N/I 

Simulation  Time  <  0  reject  invalid  simulation  time  pass 
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Figure  4.5.  Level  2  DFD 


Calculate 

Statistics 


Figure  4.6.  level  3  DFD 


Figure  4.7.  Do  System  Task 


Figure  4.8.  Do  User  Task 
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t 


To  1 

Figure  4.9.  Do  User  Task(cont) 


Figure  4.10.  Execute  Task 
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Table  4.5.  RATBSIM  Events 


Event 

Event  Information  Supplied 

Simulation-Begin 

NONE 

SimulationJEnd 

NONE 

User_Task_Execution_Start 

User  Task  Name,  User  Task  Process  Identifier  (PID),  Execution 
Start  Time 

U  ser.Task  JExecution_Stop 

User  Task  Name,  User  Task  Process  Identifier  (PID),  Execution 
Stop  Time,  Execution  Time 

User_Task_Execution 

User  Task  Name,  User  Task  Process  Identifier  (PID), 

Execution  Time  Still  Required 

User_Deadline_Met 

User  Task  Name,  User  Task  Process  Identifier  (PID),  Current 
Deadline,  Execution  Complete  Time,  Microseconds  Early 

User_Deadline_Missed 

User  Task  Name,  User  Task  Process  Identifier  (PID),  Current 
Deadline,  Execution  Complete  Time,  Microseconds  Late 

System_TaskJExecution 

System  Task  Name,  Start  Time,  Stop  Time,  Execution  Time, 
*(User  Task  Name,  User  Task  Process  Identifier  (PID)) 

User_Task_Rescheduling 

NONE 

Idle 

Start  Time,  Stop  Time,  Idle  Time 

Delay-Request 

User  Task  Name,  User  Task  Process  Identifier  (PID),  Delay 
Request,  Actual  Delay 

Call-Request 

User  Task  Name,  User  Task  Process  Identifier  (PID), 

Time  of  Call 

Accept-Request 

User  Task  Name,  User  Task  Process  Identifier  (PID), 

Time  of  Accept 

Stop_Accept 

Called  Task  Name,  Called  Task  Process  Identifier  (PID), 

Calling  Task  Name,  Calling  Task  Process  Identifier  (PID), 
Rendezvous  Complete  Time 

BAD-TIME 

Current  Time 

*  If  a  Delay  request  -  User  Task  requesting  the  Delay 
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V.  RATESIM  Validation 


The  test  cases  that  the  RATESIM  model  was  validated  against  were  described  in  Chapter  III. 
To  summarize:  the  ACEC  program  was  used  to  collect  data  on  the  target  runtime  environment  such 
as  context  switch  time,  DELAY  expiration  jitter,  and  other  pertinent  system  tasks.  The  ACEC 
data  supplied  the  parameters  for  the  system  tasks  modeled  by  RATESIM.  Finally,  various  user  task 
sets  were  constructed  (based  on  the  SEI  Hartstone  benchmark)  and  run  on  both  the  RATESIM 
model  and  the  target  hardware.  The  results  were  compared  to  further  refine  the  accuracy  of  the 
RATESIM  failure  prediction. 

The  accuracy  of  the  results  obtained  from  the  ACEC,  the  SEI  Hartstone  Benchmark,  and 
manual  code  analysis  of  portions  of  the  runtime  source  code  directly  influenced  the  validation  of 
RATESIM.  If  these  results  are  not  valid,  then  the  RATESIM  model  cannot  hope  to  be  valid. 
However,  establishing  the  accuracy  of  these  various  measurement  tools  is  not  within  the  scope  of 
this  research  and  so  the  validation  of  RATESIM  is  based  on  the  assumption  that  the  measurement 
tools  used  to  validate  it  are  correct. 

35Before  presenting  the  Hartstone  test  cases  and  results  used  to  validate  RATESIM  as  a 
whole,  the  validation  of  some  individual  components  of  RATESIM  is  discussed.  They  are:  the 
DELAY  model  (task  suspension),  system  clock  update,  the  scheduling  algorithm,  and  context 
switch/rendezvous  (task  synchronization). 

5.1  Delay  Model 

The  ACEC  test  suite  measures  the  runtime  environment  to  determine  the  additional  amount 
of  time  (T0)  a  user  task  is  suspended  (over  and  above  the  requested  delay)  versus  the  suspension 
time  the  user  task  requested  (Tr).  The  tests,  as  written,  request  DELAYs  (Tr)  of 
0  [is, 1  [is,  10  [is,  100  [is,...,  lOOOOOps.  These  tests  determined  that  Ta  ranged  from  208.40  to 
446.80 [is  for  a  given  Tr.  This  effect,  DELAY  statement  jitter,  is  a  significant  source  of  blocking  to 
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user  tasks.  A  higher  priority  task  can,  in  effect,  be  prevented  from  executing  when  it  is  otherwise 
eligible  to. 

Note  that  this  particular  source  of  blocking,  on  the  target  hardware  used  during  this  research, 
is  due  to  the  resolution  of  the  underlying  hardware  timers  and  not  due  to  system  resource  constraints 
or  a  particular  scheduling  strategy.  This  being  the  case,  it  is  not  possible  to  generalize  the  behavior 
of  a  runtime  system  DELAY  unless  the  target  hardware  uses  the  same  design.  Therefore,  RATESIM 
embedded  the  DELAY  jitter  algorithm  in  an  Ada  function  call.  This  facilitates  the  support  of 
various  DELAY  implementations  by  encapsulating  the  DELAY  jitter  effect  in  one  area  of  the 
RATESIM  model. 

Initially,  RATESIM  simply  added  the  worst  case  Ta  to  Tr  to  calculate  the  worst  case  length  of 
a  user  task  DELAY  request.  This  approach  resulted  in  an  extremely  conservative  prediction  of  task 
set  failure.  RATESIM  would  predict  a  task  set  failure  well  before  the  actual  failure  (as  observed  on 
the  target  hardware).  Although  a  conservative  prediction  of  task  set  failure  was  a  design  criteria 
for  RATESIM,  the  results  obtained  were  too  conservative.  It  was  necessary,  therefore,  to  identify 
the  sources  of  the  additional  delay  and  attempt  to  model  their  behavior  so  as  to  ultimately  achieve 
a  more  accurate  prediction.  The  details  of  the  development  of  the  DELAY  model  that  was  finally 
used  is  found  in  Appendix  A  and  is  summarized  below. 

In  order  to  construct  a  DELAY  model,  more  data  than  was  provided  by  the  ACEC  was 
needed.  Therefore,  the  ACEC  delay  test  was  modified  to  request  DELAYs  starting  at  0 /is,  and 
increase  the  DELAY  request  value  by  a  specified  amount  such  as  1  ns,  10/is,  etc.  The  data  collected 
is  presented  in  tabular  form  in  Appendix  A,  Section  A. 6. 

The  DELAY  implementation  of  the  runtime  system  (System  Designer’s  XD  Ada)  converted 
the  user  task  DELAY  request  twice  before  the  hardware  timers  were  set  with  a  DELAY  value.  First, 
the  DELAY  request  was  converted  from  type  REAL  to  type  DURATION.  Next  it  is  converted  from 
type  DURATION  to  SYSTEM.TICK.  The  error  introduced  due  to  these  conversions  is  accounted 
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for  in  the  DELAY  model  used  in  RATESIM.  By  taking  the  conversion  error  into  account,  the 
DELAY  statement  jitter  was  reduced  from  a  maximum  of  446.80/is  to  a  maximum  of  304.40/is. 
Of  the  remaining  304.40/is,  149^s  can  be  attributed  to  the  task  context  switching  and  is  assumed 
constant.  Therefore,  the  maximum  DELAY  statement  jitter  is  further  reduced  to  155.40/js.  This 
remaining  jitter  is  added  to  each  DELAY  request.  The  reduction  of  DELAY  statement  jitter  means 
that  up  to  291  Afis  of  unnecessary  blocking  in  the  RATESIM  model  (depending  on  the  DELAY 
request)  is  avoided  and  results  in  a  more  accurate  prediction  while  still  preserving  the  conservative 
nature  of  that  prediction. 

5.2  System  Clock  Update 

The  updating  of  the  system  clock  is  a  fundamental  function  provided  by  any  embedded 
runtime  environment  that  is  used  in  the  real-time  domain.  Although  the  execution  time  of  this 
function  is  typically  very  short,  it  nevertheless  consumes  CPU  time,  and  given  the  correct  task 
phasing,  could  cause  a  user  task  to  miss  a  deadline.  Therefore,  it  was  important  to  account  for  this 
system  task  in  RATESIM. 

The  ACEC  does  not  provide  a  test  to  determine  the  amount  of  CPU  time  a  clock  update 
consumes.  However,  the  amount  of  source  code  associated  with  the  clock  update  function  was 
small  enough  to  perform  a  manual  analysis  of  the  code  and  determine  the  worst  case  execution 
time  based  on  the  published  worst  case  instruction  execution  times  of  the  MC68020  and  the  worst 
case  execution  path  in  the  source  code.  This  analysis  assumed  that  the  clock  update  function  was 
never  suspended  due  to  higher  priority  interrupts.  That  is,  once  the  clock  update  began,  it  executed 
to  completion. 

Appendix  B  contains  the  analysis  of  the  clock  update  function.  The  execution  time  of  the 
XD  Ada  clock  update  was  determined  to  be  15.4/is  every  41, 600ps. 
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5.3  Scheduling  Algorithm 


The  scheduling  algorithm  used  in  RATESIM  models  a  preemptive,  event-based,  fixed  priority 
scheduler.  Preemptive  means  that  a  higher  priority  task  that  is  ready  to  execute  will  cause  the 
suspension  (or  interruption)  of  the  execution  of  any  user  task  with  a  lower  priority.  Event-based 
means  that  the  scheduling  decisions  are  made  at  the  time  a  given  event  occurs  (i.e.  a  DELAY 
expiration  or  the  completion  of  an  interrupt  service  routine).  Fixed  priority  means  that  the  priority 
of  user  tasks  do  not  change  during  their  execution.  One  exception  to  the  fixed  priority  rule  occurs 
when  two  user  tasks  rendezvous  (or  synchronize).  In  this  case,  the  tasks  will  execute  at  the  higher 
of  the  two  task’s  priorities. 

In  contrast  to  the  other  sections  within  this  chapter  which  contain  specific  data  and  analysis 
on  the  particular  aspect  of  the  behavior  in  question  to  demonstrate  its  validity,  this  section  takes  a 
different  approach.  It  will  rely  on  the  descriptions  provided  below  coupled  with  the  results  of  the 
Hartstone  benchmark  (see  Section  5.5)  as  validation  of  correct  behavior. 

To  the  reader  who  would  like  to  inspect  the  code  within  RATESIM  which  implements  the 
scheduling  behavior  described  above,  the  task  priorities  assignment  code  is  contained  in  the  proce¬ 
dure  Utility JBody,  procedures  ADD  TASK,  and  EDIT  TASK.  Scheduling  decision  code  is  embedded 
throughout  the  code  contained  in  the  procedure  Simulate-Body. 

5.3.1  Task  Priorities  User  tasks  priorities  are  assigned  based  on  RMA.  Thus,  higher  rate 
tasks  are  assigned  a  higher  priority.  The  number  of  priority  levels  is  equal  to  the  number  of  tasks 
in  the  user  task  set.  That  is,  no  two  tasks  that  would  otherwise  have  different  priorities  will  be 
forced  to  share  the  same  priority  due  to  a  fixed  number  of  priority  levels. 

Tasks  having  the  same  priority  (due  to  having  the  same  rate)  are  scheduled  on  a  FCFS  basis. 
Further,  a  task  that  is  preempted  before  it  completes  its  execution  for  a  given  period  will  be  placed 
ahead  of  user  tasks  with  the  same  priority.  This  prevents  tasks  of  the  same  priority  being  served 
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on  a  round-robin  basis  and  preserves  the  first-come-first-served  (FCFS)  nature  of  the  scheduling 
algorithm  for  tasks  of  the  same  priority. 

System  tasks  are  modeled  as  a  source  of  blocking  to  user  tasks.  They  have  no  assigned 
priority,  and  will  execute  to  completion  once  started. 

5.3.2  Scheduling  Decisions  Scheduling  decisions,  for  user  tasks,  are  made  after  the  comple¬ 
tion  of  every  system  task  execution  (except  the  context  switch).  If  there  are  more  system  tasks 
ready  to  execute,  scheduling  decisions  for  the  ready  user  tasks  are  held  off  until  such  time  that 
no  more  system  tasks  are  ready.  System  tasks  that  result  in  a  scheduling  decision  after  execution 
include: 

1)  clock  update, 

2)  DELAY  expiration, 

3)  Rendezvous  Call, 

4)  and  a  Rendezvous  Accept. 

System  tasks  are  executed  on  a  FCFS  basis.  Even  though  they  have  no  assigned  priorities  to 
distinguish  importance  or  urgency  among  other  system  tasks,  once  they  are  ready  to  execute,  they 
preempt  the  current  user  task  and  then  be  modeled  as  a  low  priority  user  task  which  is  blocking 
all  other  user  tasks  in  the  task  set. 

5.4  Context  Switch  and  Rendezvous 

The  context  switch  and  the  rendezvous  execution  times  are  measured  directly  by  the  ACEC. 
Validation  of  RATESIM  behavior  for  these  two  system  tasks  is  limited  to  a  description  of  the 
method  in  which  the  data  was  collected  (19:A126-A130).  ACEC  output  for  the  context  switch  and 
rendezvous  tests  can  be  found  in  ACEC  pretest  report  (Appendix  E). 
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5.4-1  Context  Switch  The  context  switch  is  measured  within  the  ACEC  using  the  following 
method  (ACEC  test  problems  -  tkJf-task_60,  tkJf.task.61,  tkJf.task.62): 

a)  measure  the  time  required  to  increment  a  counter  -  INCREMENT-COUNTER, 

b)  measure  the  time  required  to  execute  a  FOR  loop  NU MBER.OF .CALLS  times  (FOR 
loop  body  contains  a  DELAY  0.0)  -  ZERO  JDE LAY , 

c)  reset  the  counter, 

d)  measure  the  time  required  to  execute  a  FOR  loop  NU MBER.OF .CALLS  times  (FOR 
loop  body  contains  a  DELAY  0.01)  -  NONZERO-DELAY , 

e)  execute  the  FOR  loop  in  item  ii  above  NUM BER.OF. CALLS  times  in  a  high-priority 
task,  while  a  lower  priority  task  increments  the  counter, 

f)  save  the  counter  value  in  SAV EJNCREM ENT.COU NT, 

g)  and  finally,  the  estimated  context  switch  time  is: 

NON  ZERO  JDELAY- ZERO  JO  EL  AY— INCREMENT  .CPU  NT  ERxSAV  E -INCREMENT  .COUNT 

NUMBERj()F.CaLL$x2 

The  variable  NON  ZERO  JDELAY  contains  the  following  system  overhead  components:  con¬ 
text  switch  time  and  the  delay  overhead.  The  variable  ZERO  JDELAY  contains  the  system  over¬ 
head  component  for  the  delay.  The  variable  INC  REM  ENT.COU  NTER  and 
SAV  EJNCREM  ENT.COU  NT  contains  the  CPU  time  used  when  not  executing  the  high  pri¬ 
ority  task  NONZERO  JDELAY .  Finally,  NU  M  BER.OF. CALLS  contains  the  number  of  times 
NONZERO  JDELAY  was  called  and  therefore,  INCREMENT. COU  NTER.  After  subtract¬ 
ing  out  the  delay  overhead  and  the  time  spent  in  the  lower  priority  task,  then  dividing  by  the 
NU  M  BER.OF  .CALLS  x  2  (the  number  of  context  switches  into  NONZERO  JDELAY  and 
INC  REM  ENT.COU  NTER)  the  result  will  be  an  estimate  of  the  context  switching  time. 
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5.4-2  Rendezvous  Two  measurements  are  made  for  simple  Ada  rendezvous  in  the  ACEC: 
(1)  the  task  making  the  entry  call  arrives  first,  and  (2)  the  task  doing  the  accept  arrives  first  (ACEC 
test  problems  tkJf_task_03,  tkJf_task_23).  The  ACEC  does  this  by  assigning  a  higher  priority  to 
the  task  which  is  supposed  to  arrive  first. 

The  following  is  the  code  fragment  of  the  test  tk  Jf.task.03  (tkJf.task_23  is  similar): 


TASK  resource  IS 

PRAGMA  priorityC  zg_globl.priority_l  ); 
ENTRY  request; 

ENTRY  release; 

END  resource; 

TASK  BODY  resource  IS 
BEGIN 
LOOP 

ACCEPT  request; 

ACCEPT  release; 

END  LOOP; 

END  resource; 

TASK  BODY  main  IS 
BEGIN 

FOR  i  IN  1  . -  10  LOOP 
resource . request ; 
resource . release ; 

END  LOOP; 


It  is  possible,  in  a  given  runtime  environment,  that  the  execution  time  of  a  rendezvous  will 
differ  depending  on  whether  the  calling  or  the  accepting  task  arrives  first.  RATESIM  uses  the 
greater  of  the  two  execution  times. 

5.5  Test  Cases 

The  criteria  for  success  when  running  the  validation  test  cases  consisted  of  two  factors:  (1) 
that  RATESIM  would  predict  the  failure  of  the  user  task  set  prior  to  actual  failure  observed  when 
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executing  on  the  target  hardware,  and  (2)  that  the  failure  mode  (or  manner  in  which  the  task  set 
failed)  would  be  similar.  For  example,  if  the  user  task  set’s  failure  on  the  target  hardware  was 
manifest  by  Task  5  missing  ten  deadlines,  RATESIM  should  also  predict  that  the  failure  would  be 
from  Task  5  missing  deadlines. 

The  failure  modes  cited  in  the  tables  below  are  the  failure  modes  from  the  first  failure  of  the 
schedule  according  to  RATESIM.  Included  in  the  raw  data  in  Appendix  C  is  data  from  RATESIM 
using  the  same  task  parameters  that  caused  a  failure  using  the  Hartstone.  Also  note  that  Hartstone 
includes  the  number  of  deadlines  skipped.  Skipped  deadlines  occur  in  Hartstone  when  a  task 
misses  a  deadline  and  attempts  to  “catch  up”  by  load  shedding  (skipping  deadlines)  until  the  task 
determines  it  is  possible  to  meet  the  next  deadline.  RATESIM  does  not  incorporate  load  shedding 
since  that  is  the  responsibility  of  the  user  task.  A  runtime  environment  typically  has  no  knowledge 
of  whether  or  not  an  application  task  has  missed  a  deadline.  Therefore,  no  skipped  deadlines  will 
appear  in  the  RATESIM  failure  modes. 

A  total  of  eight  validation  tests  were  run  on  RATESIM.  The  first  three  contained  harmonic 
task  sets,  the  next  three  contained  non-harmonic  task  sets,  and  the  final  two  had  a  harmonic  task 
set  that  included  synchronization.  A  summary  of  the  results  is  contained  in  the  following  sections. 
The  actual  output  of  the  Hartstone  and  RATESIM  programs  is  contained  in  Appendix  C. 

The  Hartstone  benchmark  is  designed  such  that  the  parameter  varied  during  the  individual 
experiments  (workload  or  task  frequencies)  is  varied  at  a  given  step  size.  In  all  the  tests,  the  smallest 
step  size  possible  was  used.  Table  5.1  shows  the  parameter  varied  for  each  Hartstone  experiment. 


Table  5.1.  Hartstone  Experiments 


Hartstone 

Experiment 

Parameter  Varied 

1 

Increase  the  frequency  of  the  highest  priority  task 

2 

Increase  the  frequency  of  all  tasks 

3 

Increase  the  workload  of  all  tasks 
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5.5.1  Task  Set  A  The  purpose  of  this  task  set  was  to  validate  the  behavior  of  RATESIM 
when  executing  periodic,  harmonic  user  tasks.  In  all  experiments  (see  Table  5.2)  RATESIM  suc¬ 
cessfully  predicted  the  failure  of  the  task  set  prior  to  actual  failure.  Note  that  all  the  predictions 
RATESIM  made  fell  within  the  step  interval  that  the  Hartstone  was  able  to  achieve.  Additionally, 
in  all  experiments,  except  experiment  1,  the  RATESIM  and  Hartstone  failure  modes  were  similar. 

The  RATESIM  failure  mode  for  experiment  1  was  similar  to  Hartstone,  but  incomplete.  It 
did  not  show  any  deadlines  missed  for  the  lowest  priority  task,  Task  1.  However,  using  the  same 
task  parameters  that  caused  the  Hartstone  benchmark  to  fail,  the  failure  mode  is  both  similar  and 
complete:  Task  5-1  missed,  Task  1-13  missed. 


Table  5.2.  Test  Results  -  Task  Set  A  -  Periodic/Harmonic 


Hartstone 

Hartstone 

RAT 

ESIM 

Experi- 

Passed 

Fai 

ed 

Passed 

Fai 

ed 

ment 

Period 

Kilo- 

Period 

Kilo- 

Period 

Kilo- 

Period 

Kilo- 

Number 

Task 

(/**) 

Whets 

Whets 

(/«) 

Whets 

(A«0 

Whets 

1 

Task  5 

2 

mm 

2 

2458 

2 

mm 

2 

Task  4 

4 

4 

62500 

4 

H 

4 

Task  3 

8 

125000 

8 

125000 

8 

125000 

8 

Task  2 

250000 

16 

250000 

16 

250000 

16 

250000 

16 

Task  1 

500000 

32 

500000 

32 

500000 

32 

500000 

32 

Failure 

Mode  (Deadlines): 

Hartstone  -  Task  1:  10  missed,  10  skipped;  Task  5:  1  missed 

RATES 

!M  -  Task  5:  2  missed 

2 

Task  5 

8224 

2 

8013 

2 

8123 

2 

8122 

2 

Task  4 

16447 

4 

16026 

4 

16246 

4 

16244 

4 

Task  3 

32895 

8 

32051 

8 

32492 

8 

32488 

8 

Task  2 

65789 

16 

64103 

16 

64984 

16 

64976 

16 

Task  1 

131579 

32 

128205 

32 

129968 

32 

129952 

32 

Failure 

Mode  (Deadlines): 

Hartstone  -  Task  1:  1  met 

39  missed,  39  skipped 

RATES 

M  -  Task  1:  1  missed 

3 

Task  5 

■ 

31250 

18 

wm;  i| 

WSSSi 

a 

17.91 

Task  4 

HE] 

62500 

20 

wm 

19.91 

Task  3 

125000 

125000 

24 

125000 

125000 

23.91 

Task  2 

250000 

Mfl 

250000 

32 

250000 

31.90 

250000 

31.91 

Task  1 

500000 

47 

500000 

48 

500000 

47.90 

500000 

47.91 

Failure 

Mode  (Deadlines): 

Hartstone  -  Task  1:  10  missed,  10  skipped 

RATESIM  -  Task  1:  18  missed 
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5.5.2  Task  Set  B  The  purpose  of  this  task  set  was  to  validate  the  behavior  of  RATESIM 
when  executing  periodic,  non-harmonic  user  tasks.  In  experiments  1  and  3  (see  Table  5.3)  RATESIM 
successfully  predicted  the  failure  of  the  task  set  prioT  to  actual  failure.  Again,  note  that  the  pre¬ 
dictions  RATESIM  made  fell  within  the  step  interval  that  the  Hartstone  was  able  to  achieve. 
Additionally,  in  all  experiments,  the  RATESIM  and  Hartstone  failure  modes  were  similar. 

RATESIM  was  unsuccessful  in  predicting  the  failure  of  the  user  task  set  in  experiment  2. 
Curiously,  the  Hartstone  benchmark  failed  to  execute  a  user  task  set  whose  rate  of  execution  was 
lower  than  a  user  task  set  it  successfully  executed.  The  cause  of  this  behavior  is  most  likely  due 
to  the  runtime  optimization  associated  with  task  suspension  discussed  in  Chapter  IV,  Section  3, 
Page  4-12.  If  the  delay  for  Task  X  will  expire  within  Tw  units  of  time  of  the  delay  that  previously 
expired  for  Task  Y,  then  the  penalty  to  respond  to  Task  X’s  delay  expiration  is  much  less  than  if 
the  delay  expiration  had  occurred  after  Tw  units  of  time.  Figure  5.1  illustrates  the  window  that 
exists  in  which  the  delay  optimization  would  occur.  Figure  5.2  shows  relationship  between  the 
penalty  for  delay  expirations  that  fall  within  the  Tw  window  and  those  that  fall  outside  it.  As  the 
number  of  tasks  outside  the  window  increases,  the  penalty  increased  linearly.  The  same  is  true  for 
those  tasks  within  the  Tw  window,  but  the  rate  of  increase  is  significantly  smaller.  This  being  the 
case,  the  determining  factor  in  whether  or  not  the  increased  penalty  will  be  paid  shifts  to  whether 
or  not  delay  expirations  are  “clustered”  within  a  Tw  window.  Therefore,  it  is  possible,  just  as  was 
seen  in  Hartstone  experiment  2,  that  a  task  set  whose  frequencies  were  lower  than  another  task  set 
would  fail  while  the  task  set  with  higher  frequencies  would  pass. 

This  would  also  explain  why  this  “Tw  effect”  was  not  observed  in  the  task  sets  with  harmonic 
frequencies.  Due  to  the  very  nature  of  the  relationship  between  the  task  frequencies,  delay  expira¬ 
tions  will  fall  within  the  Tw  window.  Further,  any  jitter  within  the  expiration  of  the  delay,  given 
a  large  enough  Tw,  would  not  be  sufficient  to  push  a  task’s  delay  expiration  outside  that  window. 
With  non-harmonic  tasks  sets,  however,  the  relationship  between  the  frequencies  may  or  may  not 
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cause  them  to  fall  within  a  Tw  window  and  even  if  they  do,  delay  jitter  could  cause  the  window  to 
be  exceeded. 


Assuming  that  the  above  hypothesis  is  true,  obviously  the  Tw  that  is  modeled  within  RATESIM 
is  not  equal  to  the  Tw  that  exists  within  the  kernel  that  the  Hartstone  is  executing  under.  In  order 
to  increase  the  accuracy  of  RATESIM  and  to  predict  failures  such  as  that  experienced  during  exper¬ 
iment  2,  the  Tw  effect  within  the  the  XD  Ada  kernel  should  be  more  accurately  characterized  and 
subsequently  modeled  within  RATESIM.  A  more  specialized  test  than  that  provided  by  the  ACEC 
should  be  constructed  and  run  on  the  XD  Ada  kernel  to  determine  the  precise  point  at  which  the 
optimization  will  and  won’t  occur.  The  challenge  for  this  test  will  be  to  characterize  precisely  the 
remaining  DELAY  jitter  since  this  is  presumably  what  causes  the  optimize/no  optimize  threshold 
to  be  crossed. 


:  j  OpttnUanon  will  occur 


Tq  •  Stan  Ttno  of  Oolay  ExplrBlon 

T  »  Window  In  which  optimization  wit 
occur 

Fj  -  Penalty  tof  dalay  expiration 


I  I  Optimization  will  not  occur 


P,  -  Penalty  tor  delay  expiration 
wHtln  window 

N.  -  Number  of  delay  explratlone 
within  window 

N.  -  Number  of  delay  explratlone 
outalda  window 


Figure  5.1.  Delay  Optimization 


5.5.3  Task  Set  C  The  purpose  of  this  task  set  was  to  validate  the  behavior  of  RATESIM 
when  executing  periodic,  harmonic,  dependent  user  tasks.  In  both  experiments 
(see  Tables  5.4  and  5.5)  RATESIM  successfully  predicted  the  failure  of  the  task  set  prior  to  actual 
failure.  Note  that,  in  this  case,  the  predictions  RATESIM  made  were  more  conservative  than  in 
task  sets  A  and  B.  Even  so,  these  results  meet  the  criteria  for  successful  validation  of  the  model. 
Additionally,  in  both  experiments,  the  RATESIM  and  Hartstone  failure  modes  were  similar. 


5.6  Summary 


In  this  chapter,  the  system  task’s  behavior  modeled  in  RATESIM  was  validated  individually, 
that  is,  separate  from  the  runtime  system  execution.  From  that  perspective,  it  was  shown  that 
RATESIM  was  indeed  modeling  the  runtime  system  behavior  correctly.  Then  RATESIM  was  val¬ 
idated  as  a  whole,  that  is,  with  all  the  system  tasks  interacting  with  each  other  as  well  as  with 
the  user  task  set.  It  was  shown  that  RATESIM  successfully  met  the  objective  of  predicting  the 
scheduling  failure  of  each  user  task  sets  prior  to  the  actual  failure  in  every  case  except  one.  This 
failure,  experiment  2  in  the  non-harmonic  task  set.  was  likely  due  to  a  runtime  system  optimiza¬ 
tion  not  sufficiently  characterized  by  RATESIM.  This  hypothesis  was  discussed  and  a  method  for 
additional  research  was  suggested. 
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Number  of  Tasks 


Figure  5.2.  Delay  Penalties 


Table  5.3.  Test  Results  -  Task  Set  B  -  Periodic/Non-Harmonic 


Hartstone 

Hartstone 

RAT] 

ESIM 

Experi- 

Passed 

Fai 

led 

Passed 

Fai 

ed 

ment 

Period 

Kilo- 

Period 

Kilo 

Period 

Kilo- 

Period 

Kilo- 

Number 

Task 

(ms) 

Whets 

(Ms) 

Whets 

(M«) 

Whets 

(ms) 

Whets 

1 

Task  5 

2488 

2 

2446 

2 

2488 

2 

2487 

2 

Task  4 

145138 

4 

145138 

4 

145138 

4 

145138 

4 

Task  3 

217865 

8 

217865 

8 

217865 

8 

217865 

8 

Task  2 

434783 

16 

434783 

16 

434783 

16 

434783 

16 

Task  I 

500000 

32 

500000 

32 

500000 

32 

500000 

32 

Failure  Mode  (Deadlines): 

Hartstone  -  Task  5:  1  missed,  1  skipped 
RATESIM  -  Task  5:  3  missed 


2 

Task  5 
Task  4 
Task  3 
Task  2 
Task  1 

17551 

23409 

35139 

70126 

80645 

2 

4 

8 

16 

32 

17838 

23793 

35716 

71276 

81967 

2 

4 

8 

16 

32 

17135 

22852 

34305 

68446 

78740 

2 

4 

8 

16 

32 

17068 

22763 

34165 

68166 

78431 

2 

4 

8 

16 

32 

Failure 

Hartstoi 

RATES 

Mode  (Deadlines): 

le  -  Task  1:  1  met,  39  missed,  39  skipped 

M  -  Task  1:  1  missed 

3 

Task  5 

108814 

46 

108814 

47 

108814 

mSEi 

Task  4 

145138 

48 

145138 

49 

145138 

K 

145138 

Bin 

Task  3 

217865 

52 

217865 

53 

217865 

217865 

Bill 

Task  2 

434783 

60 

434783 

61 

434783 

60.30 

434783 

nn 

Task  1 

500000 

76 

500000 

77 

500000 

76.30 

500000 

76.40 

Failure 

Mode  (Deadlines): 

Hartstone  -  Task  1:  9  missed,  9  skipped 
RATESIM  -  Task  1:  5  missed 


Table  5.4.  Test  Results  -  Task  Set  Cl  - 


Hartstone 

Experi¬ 

ment 

Number 


Periodic/Harmonic/Synchronization 


Hartstone 


Task  3 
Task  2 
Task  1 


Entry  Call 
at  time  ( fis ) 


0 

n/a 

n/a 

n/a 

n/a 


Accept 

KWhets 

Passed 

Failed 

Period 

(M«) 

Kilo- 

Whets 

Period 

(ms) 

Kilo- 

Whets 

n/a 

9921 

2 

9827 

2 

0 

9921 

4 

9827 

4 

n/a 

39683 

8 

39308 

8 

n/a 

79365 

16 

78616 

16 

n/a 

158730 

32 

157233 

32 

RATESIM 


Passed 


Entry  Call  Accept  at 
at  time  ( fis )  time  (ns) 


0  n/a 

n/a  0 

Task  3  n/a  n/a 

Task  2  n/a  n/a 

Task  1  n/a  n/a 


Failure  Mode  (Deadlines): 
Hartstone  -  Task  1:  32  missed,  32 
RATESIM  -  Task  1:  54  missed 


Accept 

KWhets 


n/a 

0 

n/a 

n/a 

n/a 


skipped 


Period 

(ms) 


10417 

10417 

41667 

83333 

166667 


Kilo- 

Whets 


Failed 


Period  Kilo- 
(ns)  Whets 


2 

4 

8 

16 

32 


Table  5.5.  Test  Results  -  Task  Set  C2  - 


Hartstone 

Experi¬ 

ment 

Number 


Periodic/Harmonic/Synchronization 


Hartstone 


Task  2 
Task  1 


Entry  Call 
at  time  (fis) 

Accept  at 
time  (|is) 

Accept 

KWhets 

Passed 

Failed 

Period 

(ms) 

Kilo- 

Whets 

Period 

(ms) 

Kilo- 

Whets 

0 

n/a 

n/a 

8446 

0 

8224 

0 

n/a 

0 

2 

8446 

4 

8224 

4 

n/a 

n/a 

n/a 

33784 

8 

32895 

8 

n/a 

n/a 

n/a 

67568 

16 

65789 

16 

n/a 

n/a 

n/a 

135135 

32 

131579 

32 

RATESIM 


Passed 

Failed 

Entry  Call 

Accept  at 

Accept 

Period 

Kilo- 

Period 

Kilo- 

Task 

at  time  (ns) 

time  (ns) 

KWhets 

(M«) 

Whets 

(ms) 

Whets 

0  n/a  n/a  8717 
n/a  0  2  8717 
n/a  n/a  n/a  34868 
n/a  n/a  n/a  69735 
n/a  n/a  n/a  139470 


Failure  Mode  (Deadlines): 

Hartstone  -  Task  1:  38  missed,  38  skipped 
RATESIM  -  Task  1:  2  missed 


8705 

8705 

34819 

69638 

139276 
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VI.  Conclusions  and  Recommendations 


6.1  Introduction 

A  fundamental  problem  in  hard  realtime  systems  is  ensuring  that  tasks  always  meet  their 
deadlines.  The  solution  to  this  problem  is  to  develop  schedules  which  will  ensure  that  result. 
However,  since  developing  an  optimal  schedule  can  be  very  expensive  in  terms  of  time,  various 
other  scheduling  techniques  have  been  employed  to  bring  the  computational  expense  of  developing 
a  schedule  down  to  a  manageable  level.  One  difficulty  with  these  techniques,  in  the  context  of  the 
overall  system  design,  is  that  the  system  overhead  associated  with  the  execution  of  the  user  tasks 
is  either  underestimated,  poorly  understood,  or  simply  not  accounted  for  in  the  scheduling  theory. 
So,  in  spite  of  the  scheduling  algorithm’s  prediction,  task  deadlines  are  missed. 

This  research  effort’s  objective  was  three-fold: 

1)  To  demonstrate  that  intimate  knowledge  of  the  entire  runtime  environment  is  not  re¬ 
quired  to  make  an  accurate  determination  of  reserve  capacity  and  schedulability  -  that 
is,  a  subset  of  key  runtime  parameters  is  sufficient. 

2)  To  provide  insight  into  a  user  task’s  interaction  with  the  runtime  environment  during 
its  execution. 

3)  To  develop  a  parameterized  model  of  a  runtime  environment  which  provides  a  conser¬ 
vative  determination  of  task  schedulability  and  processor  reserve  capacity. 

All  these  objectives  have  been  accomplished.  The  validation  data  in  Chapter  V  demonstrated 
that  relatively  few  runtime  system  parameters  are  needed  to  accurately  predict  the  schedulability  of 
the  specified  user  tasks.  Additionally,  the  measurement  of  these  system  parameters  using  software- 
based  methods  which  depends  on  the  resolution  of  the  system  clock  does  not  adversely  affect  the 
accuracy  of  the  conservative  prediction.  Insight  into  a  user  task’s  interaction  with  the  runtime 
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system  was  provided  through  RATESIM’s  event  history.  This  event  history  enables  one  to  quickly 
determine  the  cause  of  a  missed  deadline  without  introduction  of  timing  errors.  Finally,  RATESIM 
provided  the  parameterized  model  of  a  runtime  environment  to  accomplish  the  last  objective. 
Specifically,  this  research  has  accomplished  the  following: 

i)  Confirmed  the  hypothesis  that  a  system  task  can  indeed  be  modeled  as  a  low  priority 
user  task  that  blocks  the  execution  of  a  high  priority  user  task.  This  means  that 
a  scheduling  determination  which  includes  any  blocking  a  user  task  suffers  from  the 
runtime  system,  can  be  made  by  including  runtime  system  blocking  in  the  factor  B,  in 
Equation  2.1,  Chapter  II,  repeated  below. 

Vi,  1  <  t  <  Ti,min(52^_1  <  1 

(k,l)eRi 

where  Cj  and  7}  are  the  execution  time  and  period  of  task  Tj  respectively,  =  {(ik, 

0  I  1  <  k  <  i,  l  =  1,  . . Lftj}  and  is  the  worst  case  blocking  time  for  r,-. 

ii)  Demonstrated  that  sufficient  reserve  capacity  alone  will  not  guarantee  schedulability  of 
a  user  task  set.  The  frequency  and  phasing  of  system  tasks,  relative  to  the  user  task 
deadlines,  is  inexorably  linked  to  the  schedulability  of  the  user  task  set. 

iii)  Demonstrated  that  the  concept  of  using  a  generic,  reusable,  parameterized  model  of  a 
runtime  system  is  a  viable  and  inexpensive  alternative  to  the  expensive  “build  it  and 
see  if  it  works”  approach  often  used  to  build  embedded  systems. 

iv)  Provided  the  capability  to  determine  the  schedulability  of  a  system,  early  in  the  design, 
without  the  use  of  the  target  hardware.  This  capability  will  permit  system  designers  to 
perform  a  worst-case  analysis  on  both  the  user  task  set  and  the  runtime  system.  The 
model  can  be  used  to  analyze  the  impact  of  user  task  set  changes  as  well  as  runtime 
system  changes. 
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v)  Provided  insight  into  how  to  build  better  and  more  powerful  models/simulations  of 
runtime  environments. 

vi)  Demonstrated  the  benefits  of  doing  detailed  clock  update  analysis  and  associated  delay 
modeling. 

6.2  Conclusions 

Several  conclusions  can  be  made  as  a  result  of  this  research  into  task  schedulability.  They 
are: 

1)  The  requirements  of  a  user  task  set  and  the  performance  of  the  runtime  system  must 
be  considered  and  analyzed  simultaneously!  Failure  to  do  this  will  directly  impact  the 
success  of  the  design. 

2)  Runtime  system  optimizations  can  be  extremely  sensitive  to  the  various  relationships 
between  task  parameters.  That  is,  small  changes  in  user  task  requirements,  either  in 
workload,  execution  frequency,  or  synchronization,  can  render  a  previously  schedulable 
task  set  unschedulable  even  though  the  additional  requirements  were  modest! 

3)  System  tasks  (or  system  overhead)  can  be  modeled  within  the  existing  framework  of 
the  rate  monotonic  scheduling  theory.  They  are  simply  another  source  of  blocking  and 
can  be  modeled  as  such.  No  extensions  to  the  theory  is  required.  An  execution  budget, 
similar  to  that  which  is  typically  allocated  to  user  tasks,  should  be  maintained  and 
tracked  for  system  tasks  as  well. 

6.3  Recommendations  for  Future  Research 

The  RATESIM  model  is  a  proof  of  concept  (or  demonstration)  of  a  more  accurate  way  to 
predict  the  schedulability  of  a  given  user  task  set.  However,  RATESIM  used  only  a  subset  of  the 
tasking  constructs  that  would  be  encountered  in  an  actual  embedded  system.  An  expansion  of  this 
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subset  of  tasking  constructs  is  necessary  in  the  modeling  and  schedule  prediction  of  more  realistic 
systems.  The  following  should  be  considered  for  inclusion  in  future  versions  of  RATESIM: 

i)  synchronous  and  asynchronous  I/O  support, 

ii)  user  task  critical  sections, 

iii)  aperiodic  tasks, 

iv)  more  robust  synchronization  support  such  as:  timed  entry  calls  and  parameter  passing 
during  synchronization, 

v)  dynamic  task  creation  and  deletion, 

vi)  implementation  of  the  priority  ceiling  protocol, 

vii)  and  task  communication  protocols. 

In  addition,  RATESIM  validation  was  done  on  one  particular  target  system:  a  MC68020 
running  under  the  XD  Ada  runtime  environment.  It  is  necessary,  from  the  perspective  of  further 
validation,  to  perform  similar  validation  tests  on  other  targets  and  environments. 

6.3.1  Runtime  Environment  Simulators  From  a  broader  perspective,  much  could  be  done 
to  enhance  the  capability  of  simulations  such  as  RATESIM  through  the  creation  of  descriptive 
languages  to  describe  the  behavior  of:  (1)  the  user  tasks,  and  (2)  runtime  environments  (20). 
Such  languages  would  provide  a  much  richer  characterization  of  the  user  tasks  and  runtime  en¬ 
vironments  than  that  which  is  currently  provided  in  RATESIM.  In  RATESIM,  for  instance,  the 
runtime  environment  is  defined  by  the  user  identifying  the  system  tasks  and  supplying  execution 
time  parameters;  the  scheduling  policy  and  other  implicit  behavior  of  the  runtime  environment  is 
contained  in  the  RATESIM  program  code.  Suppose,  however,  that  one  would  prefer  to  model  a 
task  set’s  behavior  under  a  different  scheduling  policy  such  as  earliest-deadline-first  to  determine 
the  viability  of  that  approach.  Or  perhaps,  runtime  environment  X  contains  optimizations  A,  B, 
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and  C  while  runtime  environment  Y  has  only  B.  Further,  it  is  conceivable  that  an  important  system 
task  might  not  be  identified  by  the  user  and  included  in  the  simulation.  These  descriptive  languages 
would  allow  such  information  to  be  easily  extracted  from  the  environment  and  exploited  within  the 
simulation  to  determine  task  set  behavior  under  a  wider  variety  of  conditions. 

Consider  Figure  6.1.  A  benchmark  such  as  the  ACEC  can  be  used  to  determine  the  timing 
behavior  of  a  runtime  environment  (or  it  could  be  supplied  by  the  compiler  vendor).  Additionally, 
a  Runtime  Environment  Description  Language  (RDL)  can  be  used  to  describe  characteristics  of  the 
compiler  and  associated  RTE  such  as:  scheduling  policy,  runtime  optimizations,  conditions  in  which 
those  optimization  occur,  and  other  information  which  would  provide  a  complete  characterization 
of  the  runtime  environment.  A  Task  Description  Language  (TDL)  can  supply  similar  information 
about  the  user  tasks  to  execute  under  the  runtime  environment:  execution  times  (worst,  best, 
and  average  case),  synchronization  points,  I/O  requirements,  critical  sections,  etc.  Using  this 
information,  a  simulator  would  construct  a  model  of  the  environment  and  “execute”  the  task  set. 
The  results  of  the  simulation  would  then  be  used  to  refine  or  modify  the  design.  If  the  target 
hardware  were  available,  the  same  TDL  could  be  used  to  automatically  construct  a  synthetic 
benchmark  to  execute  on  the  hardware.  This  would  be  valuable  for  several  purposes:  (1)  to 
evaluate  potential  targets  in  the  absence  of  the  actual  application  source  code,  (2)  as  a  further 
validation  of  the  RTE  simulator  results,  (3)  to  allow  the  description  of  benchmarks  which  more 
accurately  reflect  the  design  rather  than  relying  on  widely  used  benchmarks  which  may  or  may  not 
do  so,  and  (4)  the  automatic  benchmark  generation  capability  would  defeat  those  optimizations 
of  compilers  which  exist  only  to  boost  the  performance  of  the  generated  code  under  a  recognized 

benchmark  such  as  the  Whetstone  or  the  Dhrystone. 

» 

If  the  runtime  environment  was  also  being  built  by  the  system  designers  or  not  available, 
then  design  decisions  could  be  specified  in  RDL  and  the  impact  on  the  user  task  set  could  be 
analyzed.  This  type  of  design  and  analysis  tool  would  be  invaluable  to  designers.  The  strength  of 
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Appendix  A.  Delay  Model 


A.l  XD  Ada  Delay 

A. 1.1  Overview  The  XD  Ada  MC68020  run-time  system  implements  the  Ada  DELAY  state¬ 
ment  using  two  hardware  timers  on  the  MVME133A-20  Monoboard  Microcomputer  (14,  25).  One 
of  the  timers  ( “timer  A” )  is  used  as  a  continuously  running  “chime”  clock  and  the  other  ( “timer  D” ) 
is  used  as  an  “alarm”  clock  to  detect  events  that  occur  between  chime  clock  updates.  The  delay 
model  accounts  for  errors  introduced  into  a  given  delay  request  due  to: 

1)  Conversion  from  float  to  DURATION 

2)  Conversion  from  DURATION  to  SYSTEM.TICK 

A. 1.2  Hardware  Timers  Both  timer  A  and  timer  D  consist  of  an  8-bit  counter  and  an 
associated  prescaler  value.  The  input  frequency  to  the  timers  is  —MHz.  The  pre-scaler  value  for 
both  timers  is  200  and  so  the  resolution  of  the  timers  (and  therefore  SYSTEM.TICK)  is: 

20°(Tpfei)  =  162-5'‘s 

Elapsed  time  is  maintained  in  a  64-bit  register  with  the  lower  8-bits  being  supplied  by  timer  A. 
When  the  timer  A  counter  overflows  (every  0.0416s)  an  interrupt  is  generated  and  the  most  signifi¬ 
cant  56  bits  of  the  64-bit  register  are  incremented.  If  a  DELAY  expires  between  timer  A  interrupts, 
timer  D  is  set  to  interrupt  within  that  interval. 

A. 2  Delay  Model 

The  XD  Ada  DELAY  implementation  is  modeled  using  the  following  equation: 


ActualDelay  =  162.5  jis(/!oor(— — ^  +  1)  (A.l) 

2.0024 
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where  Delay  Request  is  the  desired  delay  in  seconds,  DURATION ’SMALL  is  2-14  seconds,  162. 5ps 
is  SYSTEM.TICK,  2.6624  is  the  ratio  (dimensionless),  and  Actual  Delay  is  the  delay  pro¬ 

duced  by  timer  A  and  timer  D  in  seconds. 

A.  2.1  Error  Sources  There  are  two  sources  of  error  in  the  XD  Ada  MC68020  implementation 
of  the  DELAY  statement.  The  first  comes  from  the  conversion  from  the  requested  delay  to  type  DU¬ 
RATION.  This  conversion  is  performed  by  the  function  round(  D v ^xtON1  'a l l  )  *n  Equation  A.l. 
The  round  function  introduces  a  maximum  of  ±0.5(DU  RATION'SM  ALL)  =  ±30.51757/is  of  er¬ 
ror. 

The  second  source  of  error  is  from  the  conversion  of  DURATION  to  SYSTEM.TICK.  The 
conversion  is  performed  by  the  function  floorQ  +  1  in  Equation  A.l.  The  error  will  be  at  most 
SYSTEM.TICK  seconds  and  at  the  least  0  seconds. 

The  worst  case  error  ranges  from  -30.51757 (is  less  than  the  requested  delay  to  193.01757/iS 
more  than  the  request  delay. 

A. 3  Sample  Calculations 

roundf 

A. 3.1  DelayRequest  —  460.0 (is  ActualDelay  =  162.5 (is(floor( - 2  6 JW  *  ")  +  1)  = 

650.0(18 

Additional  Delay  =  (650.0  —  460.0)ps  =  190ps 

This  sample  calculation  shows  how  a  delay  request  of  460.0 (is  from  a  user  application  will 
produce  a  650.0 (is  delay  at  the  hardware  timer  level.  An  additional  delay  of  190^<s. 

A. 3.2  DelayRequest  =  10100. 0/is  ActualDelay  =  162.5 (is{floor(  — )  +  1)  = 

10075.0p« 
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Additional  Delay  —  (10075.0—  10100. 0)/is=  -25.0  fjts 


This  sample  calculation  shows  how  a  delay  request  of  10100. O^s  from  a  user  application  will 
produce  a  10075.0/is  delay  at  the  hardware  timer  level.  An  additional  delay  of  -25/is. 


A. 4  Statistics  and  Model  Error 

The  data  for  the  observed  delay  graphs  was  obtained  from  the  ACEC  benchmark  test 
dt-dp-delay.01.  The  test  originally  tested  only  one  delay  request  value  and  so  was  modified  to  test 
multiple  delay  requests  at  a  specified  step  interval.  The  data  contained  in  this  appendix  is  from 
the  modified  test. 

The  descriptive  statistics  in  Table  A.l  are  the  additional  delay  observed  in  the  delay  graphs. 
Any  data  points  that  were  less  than  or  equal  to  3-8  are  not  included  in  the  descriptive  statistics  as 
those  data  points  were  actual  delays. 


Table  A.l.  Descriptive  Statistics  -  Observed  Additional  Delay 


Statistic 

Value 

Number  of  data  points 

1964 

Lower  95%  confidence  interval 

333.65 

Mean 

335.89 

Upper  95%  confidence  interval 

338.12 

Standard  deviation 

50.483 

Minimum  value 

208.40 

1st  Quartile 

305.30 

Median 

332.40 

3rd  Quartile 

370.37 

Maximum  value 

446.80 

Skew 

-0.0555 

Kurtosis 

-0.7587 

In  order  to  account  for  the  worst  case  additional  delay  in  the  RATESIM  model,  the  maximum 
model  error  must  be  found.  Figure  A.l  is  a  graph  of  the  model  error  versus  the  delay  request. 
The  model  error  is  the  difference  between  the  observed  additional  delay  and  the  model  predicted 
additional  delay.  Table  A.2  contain  the  descriptive  statistics  of  the  model  error. 


A-3 


Table  A.2.  Descriptive  Statistics  -  Model  Error 


Statistic 

Value 

Number  of  data  points 

1272 

Lower  95%  confidence  interval 

251.45 

Mean 

252.66 

Upper  95%  confidence  interval 

253.87 

Standard  deviation 

22.044 

Minimum  value 

187.20 

1st  Quartile 

237.10 

Median 

256.3 

3rd  Quartile 

270.00 

Maximum  value 

304.40 

Skew 

Kurtosis 

Recall  that  the  delay  model  only  accounts  for  the  delay  produced  by  the  hardware  timers.  The 
observed  delay  contains,  additionally,  the  context  switch  execution  time,  and  a  “delay  execution 
component”.  The  maximum  error  of  the  delay  model  is  305.  The  context  switch  as  measured  by 
the  ACEC  is  a  constant  149.  In  order  for  the  delay  model  to  always  return  the  worst  case  additional 
delay,  an  additional  156  will  be  added  to  the  delay  model  (305  -  context  switch  =  156).  Therefore, 
the  worst  case  additional  delay  is  modeled  by  adding  an  additional  305  to  the  existing  delay  model 
(Equation  A.l). 

Obviously,  the  data  in  Figure  A.l  indicates  that  a  systematic  effect  is  still  unaccounted  for 
in  the  model  error.  The  difficulty  in  determining  what  the  effect  is  is  that,  although  there  is  a 
pattern,  there  appears  to  be  no  correlation  between  the  value  and  the  original  delay  request.  As 
shown  in  Figure  A.2  for  a  given  model  prediction  of  additional  delay  the  variation  in  actual  delay 
ranges  from  187.20  to  304.40. 

One  source  of  this  variation  may  be  due  to  the  type  of  data  collected  for  the  model.  Note  the 
relatively  constant  difference  between  the  observed  and  model  additional  delay’s  in  the  1  ns  data 
(Figure  A.5).  This  relatively  constant  difference  may  also,  in  fact,  hold  in  the  delay  requests  shown 
in  the  10, 100, . . 10,  000/js  data  but  is  masked  by  the  fact  that  the  delay  requests  were  issued  in 
intervals  greater  than  1  /*«.  Therefore,  the  data  obtained  by  using  the  greater  intervals  between 
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between  delay  requests  may  be  various  points  along  a  line  similar  to  the  1  (is  data.  To  determine  if 
this  is  the  case,  more  data  should  be  taken  and  the  increase  in  delay  request  value  should  be  1/is. 
If  this  is  the  case,  the  delay  model’s  delay  execution  component  could  be  reduced  further  and  a 
more  accurate  model  would  result. 

Another  possible  source  of  this  systematic  error  could  lie  in  the  round  and  floor  functions 
used  in  the  delay  model.  If  a  random  sample  of  numbers  in  the  range  of  0  to  140,000  (is  had  the 
same  distribution  as  that  in  Figure  A.l,  it  would  confirm  this  hypothesis. 

(Observed  -  Model)  -  (is 


Figure  A.l.  (Observed  Additional  Delay  -  Model  Additional  Delay)  vs.  Delay  Request 
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A. 5  Delay  Model  and  Observed  Delay  Graphs 


The  following  section  contains  three  types  of  graphs:  (1)  delay  model,  (2)  observed  delay, 
and  (3)  the  combined  delay  model/observed  delay.  These  graphs  plot  the  requested  delay  versus 
the  additional  delay.  Additional  delay  is  defined  as  the  delay  experienced  by  the  requesting  task 
in  addition  to  what  was  requested.  The  additional  delay  in  the  observed  delay  graphs  contain 
three  distinct  components:  (1)  the  delay  produced  by  the  hardware  timers,  (2)  context  switch 
execution  time  (assumed  a  constant  149 ps  as  determined  by  the  ACEC),  and  (3)  a  ‘delay  execution 
component’  defined  as  the  time  remaining  after  (1)  and  (2)  have  been  subtracted. 

The  delay  model  graphs,  as  shown,  account  for  only  component  (1)  above.  The  context 
switch  execution  time  is  accounted  for  (in  the  RATESIM  model)  by  adding  a  constant  to  the  result 
obtained  from  the  delay  model.  The  delay  execution  component  is  accounted  for  (in  the  RATESIM 
model)  by  adding  another  constant:  the  maximum  value  of  (3)  above.  By  adding  the  context  switch 
execution  time  and  the  maximum  delay  execution  component  to  the  result  obtained  from  the  delay 
model,  the  result  will  always  be  greater  than  or  equal  to  the  maximum  observed  delay.  This  result 
is  shown  in  the  combined  delay  model/observed  delay  graphs. 
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Figure  A. 10.  Observed  Delay  -  lOOfis 
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Figure  A.ll.  Observed/Model  Delay  -  100/is 
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Figure  A.  12.  Delay  Model  -  1000/is 
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Figure  A.13.  Observed  Delay  -  1000/is 
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Figure  A. 14.  Observed/Model  Delay  -  1000/is 
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Figure  A.  15.  Delay  Model  -  10000 /is 
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Figure  A.16.  Observed  Delay  -  10000/is 
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Figure  A. 17.  Observed/Model  Delay  -  10000/is 
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Additional  Delay  -  (is 
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Figure  A.  19.  Observed  Delay  -  All  Data 
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A. 6  Raw  Data 


Table  A. 3.  l(is  data 


Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Request 

Delay 

Request 

Delay 

Request 

Delay 

Request 

Delay 

U») 

Us) 

Us) 

Us) 

U») 

Us) 

Us) 

(^s) 

0 

3.800* 

25 

12MMI 

50 

340.1 

75 

319.9 

1 

3.800* 

26 

3.800* 

51 

338.5 

76 

gjgggjHI 

2 

3.800* 

27 

3.800* 

52 

345.3 

77 

3 

3.800* 

28 

3.800* 

53 

340.3 

78 

313.8 

4 

3.800* 

29 

3.800* 

54 

327.2 

79 

308.1 

5 

3.800* 

30 

3.800* 

55 

340.0 

80 

316.0 

6 

3.800* 

31 

365.8 

56 

340.5 

81 

314.1 

7 

32 

363.4 

57 

332  3 

82 

310.1 

8 

3.800* 

33 

352.6 

58 

332.5 

83 

307.9 

9 

3.800* 

34 

359.3 

59 

330.1 

84 

314.3 

10 

3.800* 

35 

353.3 

60 

324.8 

85 

304.6 

11 

3.800* 

36 

355.3 

61 

86 

306.2 

12 

3.800* 

37 

358.7 

62 

329.0 

87 

295.8 

13 

3.800* 

38 

352.5 

63 

330.3 

88 

306.1 

14 

3.800* 

39 

357.5 

64 

326.3 

89 

299.7 

15 

3.800* 

40 

345.2 

65 

330.6 

90 

298.5 

16 

3.800* 

41 

354.4 

66 

328.7 

91 

306.0 

17 

3.800* 

42 

351.4 

67 

319.7 

92 

303.4 

18 

3.800* 

43 

351.5 

68 

328.0 

93 

297.0 

19 

3.800* 

44 

355.4 

69 

324.1 

94 

297.2 

20 

3.800* 

45 

335.8 

70 

321.0 

95 

294.5 

21 

3.800* 

46 

348.2 

71 

323.6 

96 

306.4 

22 

3.800* 

47 

346.8 

72 

317.2 

97 

298.7 

23 

3.800* 

48 

346.5 

73 

311.3 

98 

297.7 

24 

3.800* 

49 

342.8 

74 

318.3 

99 

291.8 

*  actual  delay 
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Table  A.4.  1  fis  data  (cont) 


Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Request 

Delay 

Request 

Delay 

Request 

Delay 

Request 

Delay 

(/*») 

(a**) 

(^*) 

(f*s) 

(/«) 

(/*«) 

(M«) 

(/**) 

100 

292.9 

125 

263.4 

150 

249.2 

175 

377.3 

101 

286.7 

126 

259.8 

151 

233.9 

176 

377.5 

102 

296.5 

127 

265.5 

152 

233.8 

177 

376.3 

103 

299.7 

128 

264.8 

153 

400.2 

178 

376.6 

104 

291.7 

129 

268.8 

154 

399.9 

179 

373.3 

105 

295.5 

130 

268.2 

155 

180 

374.6 

106 

282.3 

131 

263.1 

156 

397.0 

181 

374.5 

107 

290.4 

132 

261.2 

157 

397.0 

182 

370.6 

108 

284.1 

133 

254.5 

158 

396.4 

183 

371.6 

109 

281.9 

134 

261.2 

159 

394.4 

184 

368.5 

110 

282.4 

135 

258.5 

160 

393.2 

185 

111 

279.6 

136 

255.3 

161 

392.8 

186 

367.9 

112 

280.8 

137 

253.8 

162 

393.1 

187 

366.8 

113 

275.7 

138 

257.8 

163 

389.3 

188 

365.4 

114 

277.1 

139 

252.4 

164 

389.6 

189 

365.0 

115 

279.2 

140 

250.2 

165 

390.4 

190 

365.2 

116 

278.1 

141 

250.9 

166 

387.4 

191 

362.0 

117 

275.5 

142 

247.1 

167 

387.5 

192 

360.8 

118 

276.6 

143 

247.1 

168 

386.1 

193 

358.1 

119 

276.4 

144 

249.6 

384.8 

194 

360.7 

120 

266.3 

145 

244.7 

170 

386.2 

195 

359.1 

121 

275.1 

146 

237.6 

171 

383.6 

196 

359.2 

122 

272.1 

147 

248.0 

172 

381.9 

197 

356.0 

123 

269.1 

148 

237.7 

173 

380.8 

198 

357.1 

124 

263.7 

149 

244.4 

174 

378.9 

199 

356.4 

Table  A.5.  1  ns  data  (cont) 


Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Request 

Delay 

Request 

Delay 

Request 

Delay 

(H 

(A*«) 

(/**) 

(ns) 

(ns) 

(ns) 

352.8 

225 

328.5 

250 

302.4 

201 

362.4 

327.3 

251 

301.3 

202 

352.7 

227 

324.4 

252 

300.3 

203 

348.5 

228 

1^1 

253 

301.7 

204 

349.7 

229 

325.0 

254 

300.8 

205 

348.7 

230 

323.1 

255 

299.9 

206 

348.3 

231 

323.7 

256 

296.0 

207 

346.1 

232 

320.9 

257 

297.3 

208 

347.7 

233 

321.4 

258 

296.0 

209 

343.3 

234 

319.5 

259 

296.8 

210 

345.3 

235 

317.3 

260 

295.9 

211 

343.6 

236 

318.3 

212 

341.0 

237 

318.1 

213 

340.8 

238 

316.8 

214 

339.0 

239 

315.0 

215 

340.0 

240 

315.0 

216 

337.1 

241 

312.0 

217 

336.6 

242 

309.1 

218 

336.2 

243 

310.9 

219 

335.3 

244 

311.5 

220 

333.5 

245 

306.9 

221 

333.6 

246 

305.8 

222 

331.5 

247 

306.6 

223 

331.9 

248 

307.2 

224 

328.7 

249 

305.7 
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Table  A.6.  IQps  data 


Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Request 

Delay 

Request 

Delay 

Request 

Delay 

Request 

Delay 

(m«) 

(M«) 

(m«) 

(m«) 

(m«) 

(m«) 

(ms) 

(Ms) 

0 

3.800* 

250 

303.9 

500 

381.0 

750 

292.1 

10 

3.800* 

260 

294.5 

510 

369.7 

281.0 

20 

3.800* 

270 

283.9 

520 

361.5 

770 

273.3 

30 

3.800* 

280 

275.1 

530 

352.7 

780 

258.3 

40 

352.5 

290 

263.9 

540 

339.6 

790 

250.4 

50 

335.7 

300 

255.0 

550 

326.7 

800 

242.0 

60 

330.2 

310 

245.1 

560 

319.4 

810 

230.2 

70 

326.2 

320 

234.6 

570 

308.6 

820 

220.8 

80 

308.0 

330 

222.8 

580 

300.2 

830 

373.2 

90 

289.4 

MSMM 

376.1 

590 

289.7 

840 

362.6 

100 

291.3 

350 

364.5 

600 

280.7 

850 

353.6 

110 

284.0 

360 

353.5 

610 

267.0 

860 

343.9 

120 

277.0 

370 

346.4 

620 

259.9 

870 

332.9 

130 

259.1 

380 

335.2 

630 

250.8 

880 

323.2 

140 

255.4 

390 

326.5 

640 

238.4 

890 

313.9 

150 

243.2 

400 

314.2 

650 

391.7 

900 

306.9 

160 

391.1 

410 

307.0 

660 

383.1 

910 

295.8 

170 

383.0 

420 

295.5 

670 

371.5 

920 

282.3 

180 

374.5 

430 

285.7 

680 

362.1 

930 

271.6 

190 

363.7 

440 

275.6 

690 

352.8 

940 

264.9 

200 

354.6 

450 

264.1 

700 

343.9 

950 

419.3 

210 

460 

419.7 

710 

331.3 

960 

410.6 

333.5 

470 

407.9 

720 

319.4 

970 

394.4 

230 

324.0 

480 

397.1 

730 

310.2 

980 

388.0 

240 

313.8 

490 

387.6 

740 

301.8 

990 

375.0 

*  actual  delay 
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Table  A.7.  10/is  data  (cont) 


Delay 

Request 

(m«) 

Additional 

Delay 

(m«) 

Delay 

Request 

Additional 

Delay 

(m«) 

Delay 

Request 

(M«) 

Additional 

Delay 

(M«) 

Delay 

Request 

(Ms) 

Additional 

Delay 

(Ms) 

1000 

369.6 

1250 

280.1 

EEHiM 

360.6 

1750 

266.5 

1010 

358.0 

1260 

271.8 

1510 

340.1 

1760 

261.7 

1020 

348.7 

1270 

260.5 

■EEM 

332.4 

1770 

251.1 

1030 

334.4 

1280 

252.1 

1530 

325.4 

1780 

236.4 

1040 

328.6 

1290 

237.8 

1540 

315.9 

1790 

223.5 

1050 

319.0 

1300 

231.1 

1550 

303.4 

1800 

217.5 

1060 

310.3 

1310 

219.8 

1560 

297.5 

1810 

371.1 

1070 

297.3 

1320 

373.5 

1570 

291.2 

350.0 

1080 

289.6 

1330 

1580 

278.9 

1830 

350.3 

1090 

276.3 

1340 

350.2 

1590 

1840 

346.1 

1100 

264.4 

1350 

343.4 

1600 

255.3 

1850 

332.2 

1110 

257.0 

1360 

329.9 

1610 

245.3 

1860 

323.3 

1120 

246.7 

1370 

325.9 

1620 

395.4 

1870 

310.1 

1130 

396.6 

1380 

311.6 

1630 

387.4 

1880 

1140 

391.7 

1390 

299.8 

1640 

380.4 

1890 

292.2 

1150 

379.5 

1400 

292.0 

1650 

366.4 

1900 

285.5 

1160 

370.1 

1410 

281.6 

1660 

357.8 

1910 

270.3 

1170 

361.7 

1420 

268.3 

1670 

345.4 

260.1 

1180 

346.5 

1430 

262.9 

1680 

336.4 

1930 

415.9 

1190 

345.0 

1440 

414.0 

1690 

328.6 

1940 

403.9 

1200 

327.2 

1450 

406.3 

1700 

313.5 

1950 

389.4 

1210 

322.7 

1460 

397.0 

1710 

IKMH 

379.3 

1220 

308.7 

1470 

385.9 

1720 

297.4 

1970 

368.7 

1230 

298.1 

1480 

372.3 

1730 

288.1 

1980 

360.9 

1240 
~ ■  ■ 

290.4 

1490 

367.6 

1740 

281.0 

1990 

352.9 
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Table  A. 8.  10/is  data  (cont) 


Delay 

Request 

(#“) 

Additional 

Delay 

(***) 

Delay 

Request 

(/“) 

Additional 

Delay 

(m«) 

2000 

340.0 

\mmi. 

250.7 

2010 

333.3 

244.7 

2020 

316.6 

2270 

233.1 

2030 

311.0 

2280 

225.4 

2040 

301.6 

2290 

374.8 

2050 

293.9 

2300 

365.5 

2060 

278.7 

2310 

345.1 

2070 

270.0 

2320 

347.5 

2080 

262.7 

2330 

343.5 

2090 

256.2 

2340 

327.4 

2100 

243.9 

2350 

313.4 

2110 

395.4 

2360 

306.1 

2120 

387.3 

2370 

292.6 

2130 

371.3 

2380 

301.4 

2140 

364.8 

2390 

280.7 

2150 

358.1 

u 

274.3 

2160 

349.4 

2410 

254.1 

2170 

329.9 

2420 

420.9 

2180 

324.7 

2430 

415.2 

2190 

320.7 

2440 

389.5 

Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Request 

Delay 

Request 

Delay 

Request 

Delay 

Request 

Delay 

(/«) 

(/*«) 

0«) 

(/**) 

(/**) 

(/**) 

(/**) 

100 

282.1 

200 

353.1 

300 

253.6 

400 

312.9 

500 

379.7 

600 

280.2 

700 

340.5 

800 

240.2 

900 

308.8 

1000 

366.4 

1100 

266.4 

1200 

329.1 

1300 

230.4 

1400 

288.6 

1500 

354.3 

1600 

254.3 

1700 

318.4 

1800 

217.1 

1900 

275.6 

2000 

339.6 

2100 

239.4 

2200 

303.9 

2300 

370.8 

2400 

266.1 

2500 

332.1 

7600 


7700 


7800 


7900 


8000 


8100 


8200 


8300 


8400 


8500 


8600 


8700 


8800 


8900 


9000 


9100 


9200 


9300 


9400 


9500 


9600 


9700 


9800 


9900 


10000 


Table  A.  10.  100ms  data  (cont) 


Delay 

Request 

(a**) 

Additional 

Delay 

(m«) 

Delay 

Request 

(»*) 

Additional 

Delay 

(/«) 

Delay 

Request 

(/**) 

Additional 

Delay 

(/*«) 

Delay 

Request 

M 

Additional 

Delay 

(/«) 

10100 

206.9 

12600 

301.9 

15100 

221.3 

17600 

332.9 

10200 

268.4 

12700 

360.1 

15200 

284.4 

17700 

232.9 

10300 

346.8 

12800 

257.8 

15300 

361.0 

17800 

295.6 

10400 

237.0 

12900 

319.6 

15400 

240.7 

17900 

365.2 

10500 

289.7 

13000 

376.6 

15500 

307.3 

265.8 

10600 

347.9 

13100 

258.1 

15600 

393.6 

344.7 

10700 

245.0 

13200 

349.3 

15700 

303.3 

18200 

221.2 

10800 

304.8 

13300 

214.1 

15800 

355.4 

18300 

294.6 

10900 

372.1 

13400 

347.6 

15900 

412.1 

18400 

353.1 

11000 

273.8 

13500 

371.6 

16000 

319.2 

18500 

250.6 

11100 

344.4 

13600 

246.4 

16100 

391.6 

18600 

329.8 

11200 

412.2 

13700 

373.1 

16200 

280.9 

18700 

226.2 

11300 

297.2 

13800 

227.6 

16300 

327.9 

18800 

289.0 

11400 

359.9 

13900 

275.8 

16400 

417.1 

18900 

345.6 

11500 

260.0 

14000 

324.7 

16500 

293.6 

19000 

238.8 

11600 

330.7 

14100 

291.9 

16600 

370.2 

19100 

304.2 

11700 

381.2 

14200 

352.4 

16700 

266.0 

19200 

367.6 

11800 

289.7 

14300 

222.7 

16800 

309.4 

19300 

277.3 

11900 

342.9 

14400 

274.8 

16900 

402.2 

19400 

343.6 

12000 

249.8 

14500 

326.9 

17000 

285.7 

19500 

233.6 

12100 

319.7 

14600 

216.2 

17100 

344.6 

19600 

299.6 

12200 

375.0 

14700 

306.1 

17200 

254.6 

19700 

348.8 

12300 

248.2 

14800 

219.3 

17300 

330.9 

19800 

259.4 

12400 

371.4 

14900 

278.9 

17400 

374.0 

19900 

322.2 

12500 

220.7 

15000 

348.4 

17500 

270.1 

20000 

387.8 
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Table  A. 11.  lOO^s  data  (cont) 


Delay 

Request 

(/**) 

Additional 

Delay 

(n*) 

Delay 

Request 

(/**) 

Delay 

Request 

(/*«) 

Additional 

Delay 

(/**) 

Delay 

Request 

(»*>) 

Additional 

Delay 

EilliEB 

287.8 

22600 

229.3 

25100 

33o.4 

27600 

230.3 

20200 

347.7 

22700 

282.3 

25200 

369.1 

27700 

337.3 

20300 

400.5 

22800 

354.8 

25300 

289.4 

27800 

233.7 

20400 

313.4 

22900 

254.8 

25400 

318.3 

296.5 

EsHSEM 

373.2 

23000 

317.5 

25500 

405.2 

28000 

349.5 

EiEEEM 

259.7 

23100 

194.0 

25600 

283.9 

243.7 

20700 

338.9 

23200 

270.6 

25700 

358.3 

28200 

285.5 

20800 

385.2 

23300 

322.7 

25800 

284.1 

28300 

330.5 

20900 

294.9 

23400 

222.7 

25900 

306.5 

28400 

264.4 

MlfiTiTil 

347.9 

23500 

285.5 

26000 

379.6 

28500 

330.7 

21100 

264.4 

23600 

368.6 

26100 

306.1 

1IW 

377.0 

21200 

310.7 

23700 

268.6 

26200 

318.2 

28700 

273.1 

21300 

389.9 

23800 

314.9 

26300 

246.6 

28800 

363.3 

21400 

273.5 

23900 

357.3 

26400 

338.4 

28900 

236.5 

21500 

352.7 

24000 

273.8 

26500 

401.2 

29000 

295.1 

21600 

232.3 

24100 

346.2 

26600 

246.9 

29100 

379.2 

21700 

315.5 

24200 

250.1 

26700 

337.8 

29200 

237.5 

21800 

378.2 

24300 

303.2 

26800 

234.9 

29300 

351.6 

21900 

257.9 

24400 

365.9 

26900 

290.9 

29400 

22000 

341.0 

24500 

258.1 

27000 

389.4 

29500 

317.6 

22100 

241.0 

24600 

331.2 

27100 

282.7 

29600 

356.8 

22200 

294.1 

24700 

391.4 

27200 

KiZSSHI 

29700 

277.1 

22300 

356.8 

24800 

297.2 

27300 

245.4 

29800 

295.3 

22400 

266.5 

24900 

354.2 

27400 

260.7 

29900 

389.1 

22500 

312.8 

25000 

243.5 

27500 

330.3 

IE2HH 

292.0 

A-26 


Table  A. 12.  100/ia  data  (cont) 


Delay 

Request 

(/“) 

Additional 

Delay 

M 

Delay 

Request 

(/**) 

Additional 

Delay 

«) 

Delay 

Request 

(a*«) 

Additional 

Delay 

Delay 

Request 

(l**) 

Additional 

Delay 

(/**) 

30100 

331.5 

32600 

266.1 

35100 

207.2 

37600 

364.1 

30200 

345.0 

35200 

260.0 

37700 

406.5 

30300 

314.3 

32800 

EliXHH 

35300 

326.3 

37800 

326.8 

30400 

350.3 

32900 

301.3 

35400 

239.9 

37900 

389.6 

30500 

270.6 

33000 

364.1 

35500 

289.1 

38000 

319.6 

30600 

330.1 

33100 

247.6 

35600 

198.7 

38100 

371.7 

30700 

253.1 

HB 

310.4 

35700 

254.7 

38200 

394.8 

30800 

292.2 

33300 

EMKH 

35800 

331.0 

38300 

335.4 

30900 

338.5 

33400 

289.6 

35900 

207.8 

38400 

357.5 

31000 

262.1 

33500 

372.7 

36000 

270.6 

38500 

440.6 

31100 

321.6 

33600 

249.2 

36100 

187.0 

38600 

340.6 

31200 

201.3 

33700 

335.5 

36200 

249.8 

38700 

423.7 

31300 

287.6 

33800 

377.9 

36300 

296.1 

38800 

283.0 

31400 

347.2 

33900 

295.0 

36400 

192.2 

38900 

356.5 

31500 

240.4 

34000 

324.2 

36500 

345.1 

39000 

448.3 

31600 

303.1 

34100 

255.2 

36600 

387.5 

39100 

328.9 

31700 

203.1 

34200 

283.1 

36700 

287.5 

39200 

412.0 

31800 

262.0 

34300 

359.4 

36800 

350.3 

39300 

271.3 

31900 

324.8 

34400 

253.6 

36900 

433.4 

39400 

354.4 

32000 

215.1 

34500 

301.8 

37000 

283.0 

39500 

377.5 

32100 

298.2 

34600 

228.9 

37100 

375.8 

39600 

317.2 

32200 

350.3 

34700 

264.6 

37200 

275.8 

39700 

379.9 

32300 

261.0 

34800 

351.6 

37300 

358.9 

39800 

279.9 

32400 

303.4 

34900 

234.1 

37400 

401.3 

39900 

342.7 

32500 

213.1 

35000 

307.6 

37500 

321.6 

40000 

405.5 

A-27 


Table  A.13.  lOO^s  data  (cont) 


Delay 

Request 

(ms) 

Additional 

Delay 

0“) 

Delay 

Request 

(m*) 

Additional 

Delay 

(ms) 

Delay 

Request 

(ms) 

Additional 

Delay 

(ms) 

Delay 

Request 

(Ms) 

Additional 

Delay 

(ms) 

40100 

305.5 

42600 

409.6 

45100 

330.7 

47600 

272.1 

40200 

368.2 

42700 

309.6 

45200 

393.5 

47700 

334.9 

40300 

247.9 

42800 

352.0 

45300 

313.8 

47800 

397.6 

40400 

321.3 

42900 

435.2 

45400 

335.9 

47900 

318.0 

40500 

393.7 

43000 

335.2 

45500 

276.6 

48000 

360.4 

293.7 

43100 

377.6 

45600 

339.3 

48100 

280.7 

40700 

336.2 

43200 

297.9 

45700 

402.1 

48200 

313.5 

40800 

236.2 

43300 

esseihi 

45800 

281.7 

48300 

406.2 

40900 

319.3 

43400 

423.4 

364.8 

48400 

265.6 

41000 

361.7 

43500 

323.4 

46000 

427.6 

48500 

EEH&flHi 

41100 

282.0 

43600 

365.8 

46100 

337.3 

wzmmm 

41200 

324.4 

43700 

265.8 

46200 

370.0 

48700 

311.4 

41300 

397.9 

43800 

369.3 

46300 

453.1 

48800 

394.5 

41400 

307.5 

43900 

371.0 

46400 

353.1 

48900 

253.8 

41500 

350.0 

44000 

291.4 

46500 

395.5 

49000 

357.3 

41600 

433.1 

44100 

354.1 

46600 

306.2 

49100 

236.9 

41700 

333.1 

44200 

254.1 

46700 

358.3 

49200 

299.7 

41800 

375.5 

44300 

337.2 

46800 

400.7 

49300 

342.1 

41900 

295.8 

44400 

400.0 

46900 

341.4 

49400 

262.5 

42000 

338.2 

44500 

300.0 

47000 

383.8 

49500 

325.2 

42100 

421.4 

44600 

362.8 

47100 

304.2 

49600 

388.0 

42200 

321.4 

44700 

242.4 

47200 

336.9 

49700 

288.0 

42300 

384.1 

44800 

305.2 

47300 

389.0 

49800 

341.1 

42400 

426.5 

44900 

367.9 

47400 

289.0 

49900 

433.9 

42500 

346.9 

45000 

288.3 

47500 

381.8 

50000 

293.2 

A-28 


Table  A.14.  100/is  data  (cont) 


Delay 

Request 

(ms) 

Additional 

Delay 

(/**) 

Delay 

Request 

(ms) 

Additional 

Delay 

(/*«) 

Delay 

Request 

(ms) 

Additional 

Delay 

(ms) 

Delay 

Request 

(ms) 

Additional 

Delay 

(ms) 

50100 

376.3 

52600 

297.3 

55100 

401.5 

57600 

322.6 

50200 

276.3 

52700 

380.4 

55200 

291.8 

57700 

233.2 

50300 

339.0 

52800 

300.8 

55300 

384.6 

57800 

305.7 

50400 

392.1 

52900 

363.5 

55400 

447.4 

57900 

348.1 

50500 

322.1 

53000 

406.0 

55500 

347.4 

58000 

288.8 

50600 

364  5 

53100 

306.0 

55600 

410.1 

58100 

351.5 

50700 

427.3 

53200 

368.7 

55700 

310.1 

58200 

393.9 

50800 

347.7 

53300 

248.4 

55800 

372.9 

58300 

293.9 

50900 

369.7 

53400 

331.5 

55900 

435.6 

58400 

356.7 

51000 

432.5 

53500 

394.2 

56000 

335.6 

58500 

256.7 

51100 

332.5 

53600 

294.2 

56100 

368.4 

58600 

319.5 

51200 

395.2 

53700 

336.6 

56200 

278.1 

58700 

402.6 

51300 

335.9 

53800 

236.6 

56300 

361.2 

58800 

272.5 

51400 

368.7 

53900 

319.8 

56400 

423.9 

58900 

324.6 

51500 

441.1 

54000 

382.5 

56500 

283.2 

59000 

407.7 

51600 

341.1 

54100 

282.5 

56600 

366.3 

59100 

328.1 

51700 

403.9 

54200 

324.9 

56700 

266.3 

59200 

370.5 

51800 

303.9 

54300 

408.0 

56800 

349.4 

59300 

433.3 

51900 

366.6 

54400 

308.0 

56900 

412.2 

59400 

353.6 

52000 

429.4 

54500 

370.8 

57000 

312.2 

59500 

396.0 

52100 

329.4 

54600 

433.6 

57100 

375.0 

59600 

296.0 

52200 

392.2 

54700 

333.6 

57200 

275.0 

59700 

358.8 

52300 

271.8 

54800 

376.0 

57300 

337.7 

59800 

401.2 

52400 

334.6 

54900 

276.0 

57400 

359.8 

59900 

341.9 

52500 

417.7 

55000 

359.1 

57500 

280.1 

60000 

384.3 

A-29 


Table  A.15.  100/is  data  (cont) 


Delay 

Request 

(#*«) 

Additional 

Delay 

(/**) 

Delay 

Request 

(/**) 

Additional 

Delay 

(P*) 

Delay 

Request 

(M«) 

Additional 

Delay 

(/*«) 

Delay 

Request 

(*“) 

Additional 

Delay 

(M*) 

60100 

304.7 

62600 

388.5 

65100 

329.9 

67600 

434.0 

60200 

347.1 

62700 

288.5 

65200 

413.0 

67700 

334.0 

60300 

430.2 

62800 

361.9 

65300 

272.3 

67800 

376.5 

60400 

330.2 

62900 

393.7 

65400 

355.4 

67900 

276.5 

60500 

372.6 

63000 

314.0 

65500 

418.2 

68000 

359.6 

60600 

252.2 

63100 

376.8 

65600 

318.2 

68100 

402.0 

60700 

335.3 

63200 

276.8 

65700 

401.3 

68200 

302.0 

60800 

418.5 

63300 

339.5 

65800 

280.9 

68300 

385.1 

60900 

318.5 

63400 

422.6 

65900 

364.0 

68400 

447.9 

61000 

340.5 

281.9 

66000 

386.1 

68500 

307.2 

61100 

240.5 

63600 

365.0 

66100 

306.4 

390.3 

61200 

344.0 

63700 

397.8 

66200 

348.9 

68700 

290.3 

61300 

366.0 

63800 

327.8 

66300 

248.9 

68800 

373.4 

61400 

306.7 

63900 

390.6 

66400 

332.0 

68900 

436.1 

61500 

349.1 

64000 

453.3 

66500 

374.4 

69000 

336.1 

61600 

249.1 

64100 

353.3 

66600 

294.7 

69100 

378.5 

61700 

311.9 

64200 

395.7 

66700 

357.5 

69200 

278.5 

61800 

354.3 

64300 

295.7 

66800 

257.5 

69300 

341.3 

61900 

295.0 

64400 

358.5 

66900 

299.9 

69400 

424.4 

62000 

357.8 

64500 

431.9 

67000 

383.0 

69500 

324.4 

62100 

217.1 

64600 

341.6 

67100 

283.0 

69600 

387.2 

62200 

300.2 

64700 

67200 

325.4 

69700 

266.8 

62300 

342.6 

64800 

304.4 

67300 

408.5 

69800 

329.6 

62400 

283.3 

64900 

367.1 

67400 

308.5 

69900 

392.3 

62500 

305.4 

65000 

429.9 

67500 

350.9 

70000 

303.0 

A-30 


Table  A. 16.  100/is  data  (cont) 


Delay 

Request 

(»s) 

Additional 

Delay 

(H 

Delay 

Request 

(P‘) 

Additional 

Delay 

(/*») 

Delay 

Request 

(/«) 

Additional 

Delay 

Delay 

Request 

(/**) 

Additional 

Delay 

(»s) 

70100 

345.4 

72600 

296.5 

75100 

217.6 

77600 

342.1 

70200 

275.5 

72700 

349.6 

75200 

300.7 

77700 

384.5 

70300 

317.9 

72800 

442.4 

75300 

333.4 

77800 

304.8 

70400 

401.0 

72900 

352.1 

75400 

263.4 

77900 

367.6 

70500 

73000 

384.8 

75500 

326.2 

78000 

430.4 

70600 

363.7 

73100 

284.8 

75600 

389.0 

78100 

330.4 

70700 

263.7 

73200 

347.6 

75700 

289.0 

78200 

393.1 

70800 

306.1 

73300 

390.0 

75800 

351.7 

78300 

313.5 

70900 

389.3 

73400 

330.7 

75900 

425.1 

78400 

355.9 

71000 

289.3 

73500 

393.4 

76000 

294.1 

78500 

418.6 

71100 

331.7 

73600 

273.1 

76100 

377.2 

78600 

298.3 

71200 

394.4 

73700 

376.5 

76200 

277.2 

371.7 

71300 

314.8 

73800 

gras— 

76300 

340.0 

78800 

281.4 

71400 

357.2 

73900 

318.9 

76400 

402.8 

78900 

344.2 

71500 

257.2 

74000 

361.4 

76500 

323.1 

79000 

406.9 

71600 

320.0 

74100 

241.0 

76600 

355.8 

79100 

306.9 

71700 

382.7 

74200 

344.5 

76700 

EQEEHHI 

79200 

369.7 

71800 

282.7 

74300 

386.9 

76800 

298.3 

79300 

269.7 

71900 

365.8 

74400 

266.5 

76900 

411.4 

79400 

312.1 

72000 

428.6 

74500 

329.3 

77000 

453.8 

79500 

395.2 

72100 

308.2 

74600 

270.0 

77100 

353.8 

79600 

295.2 

72200 

391.3 

74700 

312.4 

77200 

386.5 

79700 

337.6 

72300 

454.1 

74800 

395.5 

77300 

316.6 

79800 

237.6 

72400 

354.1 

74900 

275.2 

77400 

359.0 

79900 

320.7 

72500 

437.2 

75000 

358.3 

77500 

EE22M 

80000 

363.1 

A-31 


Table  A.17.  100/is  data  (cont) 


Delay 

Request 

(/**) 

Additional 

Delay 

O'*) 

Delay 

Request 

O'*) 

Additional 

Delay 

O'*) 

Delay 

Request 

(P«) 

Additional 

Delay 

C*'*) 

Delay 

Request 

(***) 

Additional 

Delay 

O'*) 

80100 

283.5 

82600 

EZixEKH 

85100 

299.0 

87600 

229.8 

80200 

346.3 

82700 

287.7 

85200 

361.8 

87700 

312.9 

80300 

388.7 

82800 

330.1 

85300 

454.6 

87800 

355.3 

80400 

288.7 

82900 

372.5 

85400 

EEUBBi 

87900 

266.0 

80500 

371.8 

83000 

292.8 

85500 

397.0 

88000 

358.8 

80600 

414.2 

83100 

355.6 

317.3 

88100 

238.4 

80700 

314.2 

83200 

275.9 

85700 

359.8 

88200 

341.9 

80800 

367.3 

83300 

338.7 

85800 

wmmm 

88300 

343.6 

80900 

297.3 

83400 

360.8 

342.9 

88400 

284.3 

81000 

360.1 

83500 

301.5 

86000 

405.6 

88500 

306.3 

81100 

432.5 

83600 

354.5 

86100 

255.3 

88600 

389.5 

81200 

313.1 

83700 

264.2 

86200 

348.0 

88700 

289.5 

81300 

365.2 

83800 

306.8 

86300 

390.5 

88800 

331.9 

81400 

448.3 

83900 

389.7 

86400 

331.1 

88900 

435.3 

81500 

348.3 

84000 

269.4 

86500 

393.9 

89000 

294.6 

81600 

390.8 

84100 

352.5 

86600 

263.9 

89100 

347.7 

81700 

311.1 

84200 

394.9 

86700 

336.3 

89200 

277.7 

81800 

353.5 

84300 

285.2 

86800 

399.1 

89300 

320.1 

81900 

426.9 

84400 

378.0 

86900 

319.4 

89400 

423.6 

82000 

316.3 

84500 

278.0 

87000 

341.5 

89500 

282.9 

82100 

379.0 

84600 

340.8 

87100 

241.5 

89600 

356.3 

82200 

279.0 

84700 

383.2 

87200 

345.0 

89700 

428.8 

82300 

382.5 

84800 

283.2 

87300 

367.0 

89800 

308.4 

82400 

424.9 

84900 

366.3 

87400 

307.7 

89900 

391.5 

82500 

324.9 

85000 

429.1 

87500 

350.1 

90000 

454.3 

A-32 


Table  A.  18.  100/is  data  (cont) 


Delay 

Request 

(/*») 

Additional 

Delay 

(/«) 

Delay 

Request 

(0«) 

Additional 

Delay 

(t**) 

Delay 

Request 

(H 

Additional 

Delay 

(/*«) 

Delay 

Request 

(/«) 

Additional 

Delay 

(/*») 

90100 

354.3 

92600 

265.7 

95100 

379.5 

341.3 

90200 

417.1 

92700 

358.5 

95200 

299.9 

97700 

383.7 

90300 

317.1 

92800 

258.5 

95300 

332.6 

97800 

304.0 

90400 

379.8 

92900 

300.9 

95400 

384.7 

97900 

346.4 

90500 

442.6 

93000 

384.0 

95500 

305.0 

98000 

388.9 

90600 

342.6 

93100 

284.0 

95600 

367.8 

98100 

329.6 

90700 

425.7 

93200 

326.4 

95700 

288.1 

98200 

372.0 

90800 

93300 

409.5 

95800 

330.6 

98300 

455.1 

90900 

347.8 

93400 

299.8 

95900 

423.4 

98400 

91000 

410.5 

93500 

372.3 

96000 

293.3 

98500 

417.8 

91100 

310.5 

93600 

435.0 

96100 

356.1 

98600 

277.1 

91200 

393.6 

93700 

335.0 

96200 

256.1 

98700 

360.3 

91300 

293.6 

93800 

377.4 

96300 

318.8 

98800 

443.4 

91400 

356.4 

93900 

297.8 

96400 

402.0 

98900 

343.4 

91500 

398.8 

94000 

360.5 

96500 

292.3 

99000 

365.4 

91600 

298.8 

94100 

*23.3 

96600 

344.4 

99100 

306.1 

91700 

381.9 

94200 

323.3 

96700 

244.4 

99200 

348.5 

91800 

281.9 

94300 

365.7 

96800 

307.1 

99300 

411.3 

91900 

324.3 

94400 

428.5 

96900 

369.9 

99400 

331.6 

92000 

407.4 

94500 

328.5 

97000 

269.9 

99500 

374.1 

92100 

287.1 

94600 

411.6 

97100 

99600 

274.1 

92200 

370.2 

94700 

301.9 

97200 

405.1 

99700 

336.8 

92300 

270.2 

94800 

354.0 

97300 

295.4 

99800 

419.9 

92400 

332.9 

94900 

396.4 

97400 

337.8 

99900 

279.2 

92500 

395.7 

95000 

327.4 

97500 

278.5 

100000 

373.0 

A- 33 


Table  A.  19.  100/is  data  (cont) 


Delay 

Request 

(/*«) 

Additional 

Delay 

(/**) 

Delay 

Request 

(***) 

Additional 

Delay 

(/*«) 

Delay 

Request 

(/**) 

Additional 

Delay 

(/*«) 

Delay 

Request 

(M») 

Additional 

Delay 

0«) 

100100 

262.3 

102600 

366.5 

105100 

287.6 

107600 

412.1 

100200 

315.4 

102700 

399.2 

105200 

350.3 

107700 

312.1 

100300 

368.5 

102800 

329.3 

105300 

250.3 

107800 

364.2 

100400 

308.2 

102900 

371.7 

105400 

333.4 

107900 

407.6 

100500 

330.3 

103000 

454.8 

105500 

396.2 

108000 

317.3 

100600 

271.0 

103100 

354.8 

105600 

296.2 

108100 

400.4 

100700 

313.4 

103200 

437.9 

105700 

338.6 

108200 

100800 

396.5 

103300 

297.2 

105800 

238.6 

108300 

363.1 

100900 

276.1 

103400 

380.3 

IliMiTiTtM 

321.7 

108400 

425.9 

101000 

338.9 

103500 

443.1 

106000 

364.1 

108500 

325.9 

101100 

259.2 

103600 

343.1 

106100 

284.5 

108600 

368.3 

101200 

301.7 

103700 

405.8 

106200 

347.2 

108700 

268.3 

101300 

364.4 

103800 

305.8 

106300 

410.0 

108800 

331.1 

101400 

244.1 

103900 

348.2 

106400 

310.0 

108900 

414.2 

101500 

347.5 

104000 

421.7 

106500 

372.8 

109000 

314.2 

101600 

389.9 

104100 

331.3 

106600 

435.5 

109100 

376.9 

101700 

289.9 

104200 

394.1 

106700 

315.2 

109200 

276.9 

101800 

352.7 

104300 

294.1 

106800 

398.3 

109300 

319.3 

101900 

405.8 

104400 

356.9 

106900 

298.3 

109400 

382.1 

102000 

335.8 

104500 

419.6 

107000 

320.3 

109500 

261.8 

102100 

378.2 

104600 

299.3 

107100 

403.5 

109600 

344.9 

102200 

257.9 

104700 

382.4 

107200 

303.5 

109700 

265.2 

102300 

341.0 

104800 

282.4 

107300 

386.6 

109800 

307.6 

102400 

403.7 

104900 

324.8 

107400 

449.3 

109900 

370.4 

102500 

324.1 

105000 

387.6 

107500 

349.3 

110000 

270.4 
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Table  A. 20,  100/is  data  (cont) 


Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Delay 

Additional 

Request 

Delay 

Request 

Delay 

Request 

Delay 

Request 

Delay 

(m«) 

(m«) 

(ms) 

(m«) 

(Ms) 

(Ms) 

(ms) 

(ms) 

110100 

353.5 

112600 

274.5 

115100 

378.7 

117600 

320.1 

110200 

416.2 

WEHiTiM 

337.3 

115200 

278.7 

117700 

382.9 

110300 

295.9 

112800 

420.4 

115300 

117800 

282.9 

110400 

ESIZlHH 

112900 

320.4 

115400 

404.2 

117900 

345.6 

110500 

269.3 

113000 

342.5 

115500 

304.2 

118000 

408.4 

110600 

321.4 

113100 

283.2 

115600 

357.3 

118100 

308.4 

110700 

404.5 

113200 

325.6 

115700 

429.8 

118200 

350.8 

110800 

284.2 

113300 

115800 

329.8 

118300 

271.2 

110900 

367.3 

113400 

115900 

372.2 

118400 

333.9 

111000 

430.0 

113500 

371.4 

116000 

Esmi 

118500 

366.6 

111100 

289.4 

113600 

260.8 

116100 

334.9 

118600 

276.3 

111200 

362.8 

113700 

313.9 

116200 

418.0 

118700 

111300 

455.6 

113800 

356.3 

116300 

318.0 

118800 

259.4 

■new 

355.6 

113900 

297.0 

116400 

380.8 

118900 

322.2 

sr*mni» 

398.0 

114000 

319.0 

443.6 

119000 

364.6 

111600 

288.3 

114100 

239.4 

116600 

343.6 

119100 

264.6 

111700 

360.7 

114200 

302.1 

406.3 

119200 

317.7 

111800 

403.2 

114300 

385.3 

116800 

296.6 

119300 

410.5 

111900 

323.5 

114400 

264.9 

116900 

369.1 

119400 

290.1 

112000 

386.3 

114500 

327.7 

117000 

431.8 

119500 

373.2 

112100 

265.9 

114600 

370.1 

117100 

331.8 

IllEEIiTM 

^£££■11 

112200 

349.0 

114700 

290.4 

117200 

374.3 

119700 

326.3 

112300 

391.4 

114800 

332.8 

117300 

294.6 

119800 

378.4 

■iwunM 

332.1 

114900 

395.6 

117400 

337.0 

119900 

298.8 

112500 

394.9 

115000 

336.3 

117500 

420.1 

120000 

351.8 

Table  A.21.  100/is  data  (cont) 


122300 


122400 


122500 


Delay 

Request 

(**«) 

Additional 

Delay 

(na) 

Delay 

Request 

O'*) 

Additional 

Delay 

(/**) 

Delay 

Request 

(M*) 

Additional 

Delay 

(/**) 

120100 

424.3 

122600 

325.0 

125100 

307.1 

120200 

324.3 

122700 

225.0 

IWEE-fliTM 

339.8 

120300 

366.7 

122800 

328.5 

125300 

391.9 

120400 

449.8 

122900 

370.9 

125400 

332.6 

120500 

349.8 

123000 

291.2 

125500 

375.0 

120600 

412.6 

123100 

354.0 

125600 

254.7 

120700 

292.2 

123200 

416.7 

125700 

378.5 

120800 

355.0 

123300 

296.4 

BPEETiTiMKETilt— i 

120900 

397.4 

123400 

359.1 

125900 

320.9 

121000 

317.7 

123500 

279.5 

126000 

363.3 

121100 

380.5 

123600 

321.9 

126100 

243.0 

121200 

280.5 

123700 

405.0 

126200 

326.1 

121300 

343.3 

123800 

305.0 

126300 

388.8 

121400 

426.4 

123900 

327.1 

126400 

268.5 

121500 

326.4 

124000 

410.2 

126500 

371.9 

121600 

389.1 

124100 

310.2 

126600 

231.2 

121700 

268.8 

124200 

372.9 

126700 

314.3 

121800 

351.9 

124300 

456.1 

126800 

377.1 

121900 

414.6 

124400 

mi1 

126900 

247.1 

122000 

314.6 

124500 

378.1 

127000 

319.5 

122100 

377.4 

124600 

318.8 

127100 

412.3 

122200 

257.1 

124700 

361.2 

127200 

302.6 

124800 


124900 


125000 


Table  A.22.  1000/is  data 


Delay 

Request 

(H 

Additional 

Delay 

(H 

Delay 

Request 

(***) 

Additional 

Delay 

(f*s) 

Delay 

Request 

(/*») 

Additional 

Delay 

(/*«) 

Delay 

Request 

(H 

Additional 

Delay 

(/**) 

1000 

369.6 

26000 

387.1 

51000 

452.8 

76000 

294.1 

2000 

340.3 

27000 

353.6 

52000 

429.4 

77000 

453.8 

3000 

313.0 

28000 

330.2 

53000 

406.0 

78000 

430.4 

4000 

289.0 

29000 

292.2 

54000 

362.2 

79000 

386.6 

5000 

277.0 

30000 

302.7 

55000 

349.4 

80000 

373.8 

6000 

237.6 

31000 

251.8 

56000 

294.9 

81000 

339.7 

7000 

393.4 

32000 

208.3 

57000 

271.5 

82000 

316.3 

8000 

346.3 

33000 

364.1 

58000 

288.8 

83000 

313.2 

9000 

340.6 

34000 

361.0 

59000 

387.4 

84000 

249.1 

10000 

318.7 

35000 

296.9 

60000 

404.7 

85000 

408.7 

11000 

287.6 

36000 

284.1 

61000 

381.2 

86000 

426.0 

12000 

239.8 

37000 

292.7 

62000 

317.1 

87000 

341.5 

13000 

415.3 

38000 

309.9 

63000 

334.3 

88000 

318.1 

14000 

359.9 

39000 

428.9 

64000 

433.0 

89000 

315.0 

15000 

336.5 

40000 

385.1 

65000 

429.9 

90000 

433.9 

16000 

319.2 

41000 

361.7 

66000 

406.4 

91000 

410.5 

17000 

302.2 

42000 

338.2 

67000 

383.0 

92000 

387.1 

18000 

262.3 

43000 

314.8 

68000 

359.6 

93000 

384.0 

19000 

255.3 

44000 

261.3 

69000 

i^m1 

94000 

340.2 

20000 

401.4 

45000 

267.9 

70000 

312.7 

95000 

316.8 

21000 

347.9 

46000 

427.6 

71000 

289.3 

96000 

293.3 

22000 

344.9 

47000 

363.5 

72000 

387.9 

97000 

290.2 

23000 

324.0 

48000 

340.0 

73000 

405.1 

98000 

429.6 

24000 

284.4 

49000 

316.6 

74000 

361.4 

99000 

385.8 

25000 

260.0 

50000 

333.9 

75000 

358.3 

100000 

342.0 
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Table  A.23.  1000/js  data  (cont) 


Delay 

Request 

(m«) 

Additional 

Delay 

(m«) 

Delay 

Request 

(m«) 

Additional 

Delay 

(m«) 

Delay 

Request 

(ms) 

Additional 

Delay 

(ms) 

Delay 

Request 

(M«) 

Additional 

Delay 

(M«) 

101000 

359.2 

126000 

343.0 

151000 

387.7 

176000 

402.5 

102000 

295.1 

127000 

339.9 

152000 

343.9 

177000 

409.0 

103000 

454.8 

128000 

336.8 

153000 

340.8 

178000 

wsmm 

104000 

431.3 

129000 

455.7 

154000 

307.7 

179000 

341.8 

105000 

387.6 

130000 

432.3 

155000 

426.7 

180000 

338.7 

106000 

343.8 

131000 

408.9 

156000 

412.9 

181000 

448.0 

107000 

310.7 

132000 

385.4 

157000 

389.5 

182000 

413.9 

108000 

337.6 

133000 

352.3 

158000 

386.4 

183000 

410.8 

109000 

273.5 

134000 

319.2 

159000 

322.3 

184000 

337.0 

110000 

290.7 

135000 

274.4 

160000 

339.5 

IT— 

wmmm 

111000 

409.7 

136000 

251.0 

161000 

316.1 

186000 

320.2 

112000 

406.6 

137000 

390.3 

162000 

292.7 

187000 

317.1 

113000 

362.8 

138000 

407.6 

163000 

452.3 

188000 

252.9 

114000 

359.7 

139000 

354.1 

164000 

367.9 

189000 

433.0 

115000 

316.0 

140000 

340.3 

165000 

385.1 

190000 

368.8 

116000 

141000 

337.3 

166000 

321.0 

191000 

386.1 

117000 

411.5 

142000 

435.9 

167000 

317.9 

192000 

362.7 

118000 

388.0 

143000 

432.8 

168000 

457.2 

193000 

298.5 

119000 

344.3 

144000 

409.4 

169000 

433.8 

194000 

275.1 

120000 

320.8 

145000 

385.9 

170000 

410.3 

195000 

434.8 

121000 

338.1 

146000 

362.5 

171000 

386.9 

196000 

411.3 

122000 

314.6 

147000 

339.0 

172000 

363.5 

197000 

387.9 

123000 

281.5 

148000 

315.6 

173000 

340.0 

198000 

364.4 

124000 

389.8 

149000 

251.5 

174000 

275.9 

199000 

300.3 

125000 

407.1 

150000 

411.1 

175000 

293.1 

200000 

276.9 
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Table  A.24.  lOOO^a  data  (cont) 


Delay 

Request 

Additional 

Delay 

(»«) 

Delay 

Request 

(^«) 

Additional 

Delay 

(/“) 

Delay 

Request 

(/**) 

Additional 

Delay 

(/*«) 

Delay 

Request 

(/*«) 

Additional 

Delay 

(/**) 

201000 

294.1 

226000 

298.2 

251000 

276000 

202000 

ESsEM 

227000 

254.4 

252000 

319.5 

277000 

303.3 

203000 

389.7 

228000 

393.7 

253000 

296.1 

278000 

300.1 

204000 

386.6 

229000 

411.0 

254000 

415.1 

279000 

256.4 

205000 

342.8 

230000 

367.2 

255000 

412.0 

280000 

436.4 

206000 

319.3 

231000 

323.4 

256000 

368.2 

281000 

372.3 

207000 

295.9 

232000 

340.7 

257000 

324.4 

282000 

369.2 

208000 

435.2 

233000 

296.9 

258000 

301.0 

283000 

325.4 

209000 

371.1 

234000 

436.2 

259000 

288.2 

284000 

322.3 

210000 

378.7 

235000 

372.1 

260000 

396.5 

285000 

278.5 

211000 

364.9 

236000 

389.3 

261000 

413.8 

286000 

438.2 

212000 

341.5 

237000 

365.9 

262000 

380.6 

287000 

394.4 

213000 

318.0 

238000 

342.5 

263000 

326.2 

288000 

380.6 

214000 

253.9 

239000 

319.0 

264000 

343.4 

289000 

367.8 

215000 

433.9 

240000 

275.3 

265000 

279.3 

290000 

303.8 

216000 

369.8 

241000 

414.6 

266000 

276.2 

291000 

300.6 

217000 

366.7 

242000 

411.5 

267000 

415.6 

292000 

256.9 

218000 

343.3 

243000 

367.7 

268000 

392.1 

293000 

436.8 

219000 

319.8 

244000 

344.3 

269000 

368.7 

294000 

372.8 

220000 

276.1 

245000 

300.5 

270000 

m 

295000 

369.7 

221000 

435.7 

246000 

297.4 

271000 

iHEm 

296000 

346.2 

222000 

371.6 

247000 

436.7 

272000 

298.4 

297000 

322.8 

223000 

388.8 

248000 

372.6 

273000 

437.7 

298000 

279.0 

224000 

365.4 

249000 

389.8 

274000 

414.3 

299000 

418.3 

225000 

321.6 

250000 

366.4 

275000 

390.8 

300000 

394.9 
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Table  A.25.  lOOO^s  data  (cont) 


Delay 

Request 

(ms) 

Additional 

Delay 

(ms) 

Delay 

Request 

(m») 

Additional 

Delay 

(ms) 

Delay 

Request 

(ms) 

Additional 

Delay 

(ms) 

301000 

371.4 

326000 

395.8 

351000 

440.6 

302000 

368.3 

327000 

392.8 

352000 

417.2 

303000 

304.2 

328000 

369  3 

353000 

383.1 

304000 

321.5 

329000 

325.5 

354000 

349.9 

305000 

257.3 

330000 

281.8 

355000 

316.8 

306000 

437.3 

331000 

299.0 

356000 

323.4 

307000 

393.6 

332000 

357000 

KTiTSTiTiM 

360.5 

333000 

374.2 

358000 

256.2 

309000 

326.3 

334000 

350.8 

359000 

310000 

323.3 

335000 

347.7 

IKTi— 

372.1 

311000 

299.8 

336000 

324.3 

361000 

348.7 

312000 

418.8 

337000 

280.4 

362000 

325.2 

313000 

415.7 

338000 

399.4 

363000 

271.8 

314000 

392.3 

339000 

416.7 

364000 

400.4 

315000 

328.2 

340000 

393.3 

316000 

345.4 

341000 

329.1 

317000 

281.3 

342000 

346.4 

318000 

298.5 

343000 

272.6 

319000 

254.7 

344000 

269.5 

320000 

373.7 

345000 

276.1 

321000 

350.3 

346000 

395.0 

322000 

336.5 

347000 

371.6 

323000 

303.4 

348000 

348.2 

324000 

280.0 

349000 

304.4 

325000 

419.3 

350000 

280.9 
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Table  A.26.  10,000/xs  data 


Delay 

Request 

(»s) 

Additional 

Delay 

(^s) 

Delay 

Request 

Additional 

Delay 

(/**) 

Delay 

Request 

Additional 

Delay 

Delay 

Request 

(/*«) 

Additional 

Delay 

(/*«) 

10000 

311.5 

260000 

437.2 

510000 

355.9 

760000 

294.9 

20000 

384.9 

270000 

345.3 

520000 

426.7 

770000 

345.3 

30000 

268.8 

280000 

416.0 

530000 

334.7 

780000 

416.1 

40000 

405.5 

290000 

324.1 

540000 

242.9 

790000 

324.2 

50000 

313.5 

300000 

415.2 

550000 

313.6 

800000 

415.4 

■tMifiTi  MM 

384.3 

310000 

323.3 

EffiiTiTiTiM 

404.7 

810000 

323.3 

70000 

303.0 

320000 

394.1 

570000 

312.8 

820000 

394.1 

80000 

383.5 

330000 

302.1 

580000 

383.6 

830000 

322.5 

90000 

454.3 

340000 

393.3 

1— ffiM 

311.9 

840000 

393.3 

100000 

350000 

280.9 

600000 

EZggjJHil 

850000 

301.4 

110000 

290.7 

360000 

351.8 

610000 

281.1 

860000 

392.6 

120000 

361.5 

370000 

259.8 

620000 

361.6 

870000 

300.6 

130000 

432.3 

380000 

371.3 

630000 

269.6 

371.3 

140000 

340.3 

390000 

442.1 

640000 

340.4 

890000 

442.1 

150000 

431.5 

400000 

329.8 

650000 

431.6 

900000 

329.8 

160000 

319.2 

410000 

237.8 

660000 

339.7 

910000 

278.7 

170000 

369.6 

420000 

349.3 

670000 

920000 

339.7 

180000 

338.7 

430000 

379.4 

680000 

318.4 

930000 

420.2 

190000 

368.8 

440000 

328.2 

690000 

389.2 

940000 

307.9 

200000 

297.2 

450000 

378.6 

700000 

317.6 

950000 

389.3 

210000 

347.7 

460000 

286.7 

710000 

388.4 

960000 

286.7 

220000 

296.4 

470000 

357.4 

720000 

296.4 

970000 

398.2 

230000 

387.5 

480000 

296.5 

730000 

367.4 

980000 

306.3 

240000 

265.6 

490000 

356.6 

740000 

295.6 

990000 

397.5 

250000 

325.7 

500000 

285.1 

750000 

366.4 
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Appendix  B.  System  Clock  Update  Analysis 


B.  1  Overview 

The  XD  Ada  MC68020  run-time  system  clock  is  updated  every  162.5ps  and  generates  an 
interrupt  that  the  runtime  system  must  handle  every  256-  162.5 ps  =  41,600 ps.  Since  the  clock 
interrupt  handler  is  short  and  there  are  only  two  execution  paths,  it  readily  lends  itself  to  manual 
analysis.  The  interrupt  handler  is  reproduced  in  Section  B.3  (used  by  permission  (13)).  To  insure 
the  worst  case  execution  time,  the  analysis  assumed  the  worst  case  execution  path.  The  number 
of  clock  cycles  to  execute  a  given  instruction  is  contained  within  square  braces  (e.g.  [  ]).  Since 
the  MC68020  is  a  pipelined  architecture  and  there  is  no  method  of  predicting  the  state  of  the 
pipeline  at  an  arbitrary  point  in  time,  worst  case  execution  times  are  assumed.  Also  note  that 
the  MVME133A-20  single  board  computer  inserts  1  wait  state  for  every  memory  reference  (14:31). 
This  wait  state  is  accounted  for  in  the  execution  time  indicated. 

B.2  Interrupt  Response  Time 

The  response  time  for  an  M-Stack  interrupt  is  48  clock  cycles  (15:10-40).  In  addition,  there 
are  12  memory  references  associated  with  the  interrupt  response  cycle  which  results  in  12  wait 
states.  Therefore,  the  worst  case  interrupt  response  time  is  60  clock  cycles  once  the  interrupt  has 
been  recognized.  Actually,  it  may  take  significantly  longer  for  the  clock  interrupt  to  be  recognized 
due  to  hardware  interrupt  priorities  and  the  fact  that  pending  interrupts  are  only  recognized  after 
the  execution  of  the  current  instruction.  The  MOVEM  instruction,  however,  is  an  exception  to 
this  rule.  Pending  interrupts  are  not  recognized  after  the  execution  of  a  MOVEM  instruction,  but 
rather  recognition  is  delayed  until  the  instruction  following  MOVEM. 

This  interrupt  recognition  latency  has  not  been  included  in  this  analysis  since,  in  the  context 
of  this  research,  it  does  not  induce  any  blocking  with  respect  to  RMA.  Only  the  actual  interrupt 
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response  time  and  interrupt  handler  block  a  user  task.  The  time  to  recognize  that  an  interrupt 
occurred,  in  fact,  does  not  penalize  the  user  task  whatsoever. 
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B.S  Interrupt  Handler 


DDODD 
D  D 
D  D 

D  D 

D  D 

D  D 
DDDDD 


All  DDDDD  AAA 

A  A  D  D  A  A 

A  A  D  D  A  A 

AAAAAAA  D  D  AAAAAAA 
A  A  D  D  A  A 

A  A  D  D  A  A 

A  A  DDDDD  A  A 


* 

*  COPYRIGHT  (c)  1988,1991  BY 

*  DIGITAL  EQUIPMENT  CORPORATION  MAYIARD,  MASS. 

*  ALL  RIGHTS  RESERVED. 

*  COPYRIGHT  (c)  1988,1991  BY 

*  SD-SCICOI  PLC,  FLEET,  HAMPSHIRE,  El G LA ID . 

*  ALL  RIGHTS  RESERVED. 

* 

*  THIS  SOFTWARE  IS  FURIISHED  UVDER  A  LICE1SE  AID  MAY  BE  USED  AID  COPIED 

*  OILY  II  ACCORD AICE  WITH  THE  TERMS  OF  SUCH  LICEISE  AID  WITH  THE 

*  IICLUSIOI  OF  THE  ABOVE  COPYRIGHT  IOTICE. 

* 

*  THE  IIFORHATIOI  II  THIS  SOFTWARE  IS  SUBJECT  TO  CHARGE  WITHOUT  IOTICE 

*  AID  SHOULD  IOT  BE  COISTRUED  AS  A  COMMITMEIT  BY  DIGITAL  EQUIPMENT 

*  CORPORATIOI  OR  SD-SCICOI  UK  LTD. 

* 


TITLE  "CLOCK" 

MODULE  "CLOCK" 

IDEVT  "V1.2A-33" 

*  This  nodule  provides  the  run- tine  system  support  for  package 

*  CALEIDAR,  and  provides  time-out  support  for  the  TASKIIG  system. 

*  It  implements  the  clock  interrupt  handlers,  together  vith  routines 

*  to  initialise  the  timer(s)  and  return  the  current  time.  It  also 

*  contains  routines  which  are  called  from  the  Target  Kernel  to 

*  stop  and  restart  the  clock. 


* —  procedure  COMMOI.HAIDLER  is 

* —  begin 

* —  —  This  routine  is  the  interrupt  handler  for  both  the  chiming 

* —  —  clock  and  the  alarm  clock  if  both  exist,  both  use  the  same 

* —  —  interrupt  vector,  and  tasking  is  present. 

♦--  if  GLt_DELAY_TIMER  >=  0  then 
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CHIME.  HA  IDLER; 

* —  else 

*—  ALARM. HAIDLER; 

* —  end  il ; 

*—  end  COMMOI.HAIDLER ; 

COMMOI.HAIDLER : 

TST.L  GL$_DELAY_TIMER . L  [13] 

BGE.V  CHIME.HAIDLER  [11,  branch  taken] 

BRA. V  ALARM.HAIDLER 


* 


* —  procedure  CLR.CHIME; 

*—  pragma  IILIIE  (CLR.CHIME) ; 

* —  —  This  macro  need  only  be  provided  il  a  chiming  clock  is  used. 

* —  —  MACRO  CLR.CHIME  is  called  as  the  lirst  action  within  the 

* —  —  chiming  timer's  interrupt  handler.  It  should  clear  the  chiming 

* —  —  timer's  interrupt.  In  addition,  il  both  a  chiming  clock  and  an 

* —  —  alarm  clock  are  being  used,  it  is  recommended  that  this  macro 

* —  —  also  makes  sure  that  the  alarm  timer  is  stopped.  This  macro 

* —  —  must  not  modily  any  registers. 

CLR.CHIME:  MACRO 

AIDI.B  #$F8 , CLI.TCDCR  [17] 

EIDMAC 


* 


* —  procedure  SET.ALARM  (TICKS  :  in  IITEGER); 

pragma  IILIIE  (SET.ALARM); 

* —  —  This  macro  need  only  be  provided  il  an  alarm  clock  is  used 

* —  —  It  should  set  the  alarm  clock  to  interrupt  alter  TICKS 

* —  —  SYSTEM. TICKs,  where  TICKS  is  always  contained  in  register 

* —  —  DO.L.  TICKS  will  always  be  in  the  range  1 . .MAX. ALARM.  This 

* —  —  macro  must  not  modily  any  registers  other  than  DO. 


SET.ALARM: 


MACRO 

AIDI.B 

#$F8 , CLI.TCDCR 

[17] 

MOVE.B 

DO , CLl.TDDR 

[9] 

ORI.B 

#807 , CLI.TCDCR 

[17] 

EIDMAC 

* —  procedure  CHIME.HAIDLER  is 

* —  begin 

* —  —  This  routine  is  the  chiming  dock  interrupt  handler  il  both  a 
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* — 


—  chining  clock  and  an  alarm  clock  exist,  tasking  is  present, 
* —  —  and  HAX.ALARM  is  greater  than  or  equal  to  CHIME.PERIOD . 

*—  CLR.CHIME; 

*—  GL$_CLDCK  :=  GL$_CLOCK  +  CHIME_PERIOD ; 

*—  il  GL$_DELAY_TIMER  >  0  then 

if  GL$_DELAY_TIMER  <  CHIME.PERIQD  then 
*—  SET_ALARM  (GL$_DELAY_TIMER) ; 

* —  end  if ; 

*—  GL$_DELAY_TIMER  :=  GL$_DELAY_TIMER  -  CHIME.PERIOD; 

* —  else 

*—  GL$_REQUESTS  (T$_RQ_ALARM)  :=  TRUE; 

* —  end  if ; 

*—  end  CHIME.HAIDLER ; 


CHIME_H ANDLER : 


CLR_CHIME 

ADDI.L 

#CHIME_PERI0D , GL$_LS_CLOCK . L 

[17] 

[23] 

BCC.B 

CH_I0_CARRYi 

[6,  not  taken] 

ADDQ.L 

#1 , GL$_MS_CL0CK . L 

[17] 

CH_I0_CARRY 1 : 

MOVE.L 

D0.-(A7) 

[8] 

CH_IF1 : 

MOVE . L 

GL$_DELAY_TIMER . L , DO 

[13] 

BLE.V 

CH.ELSE1 

[8,  not  taken] 

CH.THEIl: 

CH_IF2 : 

CMPI.L 

#CHIME_PERI0D , DO 

[10] 

BGE.V 

CH.EIDIF2 

[8,  not  taken] 

CH_THEI2 : 

SET.ALARM 

[43] 

CH_ESDIF2 : 

SUBI.L 

BRA.B 

#CHIME_PERI0D , 

GL$_DELAY_TIMER . L 

CH.EIDIFl 

[18] 

[11,  taken] 

CH_ELSE1 : 

BSET.B 

#T$_RQ_ALARM , GL$ .REQUESTS . L 

CH.EIDIFl : 

MOVE.L 

(A7)+,D0 

[9] 

MOVE.L 

GLS_IIT_RETURI . L,-(A7) 

[18] 

RTS 

[IS] 

B-4  Clock  Update  Analysis 

The  number  of  clock  cycles  required  to  update  the  system  clock  and  return  is  the  summation 
of  the  interrupt  response  time  (60  clock  cycles)  and  the  interrupt  handler  (248  clock  cycles).  Each 
clock  cycle  takes  2on/j if,  =  0.05/is.  Therefore,  the  time  required  to  update  the  system  clock  is: 

(248  +  60)  x  0.05/is  =  15.4/js 
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Since  the  clock  is  updated  every  41600^3,  the  worst  case  CPU  utilization  for  clock  updates 


is 


15.4 

41600 


0.0370%. 
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Appendix  C.  Hartstone/RATESIM  Validation  Data 


This  appendix  contains  the  raw  validation  data  gathered  during  the  testing  of  the  RATESIM 
model.  Each  section  contains  the  summary  Hartstone  benchmark  results  and  three  RATESIM 
model  runs.  The  first  RATESIM  run  is  of  the  last  point  in  which  RATESIM  determined  that  the 
user  task  set  was  schedulable,  the  second  run  in  the  first  point  at  which  the  user  task  set  failed, 
and  the  last  run  is  of  the  user  task  set  using  the  same  task  parameters  at  which  the  task  set  failed 
on  the  target  hardware  while  running  the  Hartstone  benchmark. 


C.l  Task  Set  A  -  Harmonic 


C.1.1  Hartstone  Results  -  Experiment  1 


HARTSTOIE  BEICHMARK  SUMMARY  RESULTS 


Baseline  test: 


Experiment :  EXPERIMENT. 1  HARMOIIC 
Completion  on:  Miss/skip  SO  deadlines 

Ran  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.78 
Test  1  characteristics: 


Task 

Frequency 

Kilo-Vhet s 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  X 

2 

4.00 

16 

64.00 

4.79  X 

3 

8.00 

8 

64.00 

4.79  % 

4 

16.00 

4 

64.00 

4.79  % 

6 

32.00 

2 

64.00 

4.79  % 

320.00 

23.94  X 

Experiaent  step  size:  2.39  % 


Test  1  results: 
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Test  duration  (seconds):  10.0 


Task 

Period 

Met 

Missed 

Skipped 

Average 

Ko. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

250.000 

40 

0 

0 

0.000 

3 

125.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

31.250 

320 

0 

0 

0.000 

Last  test  with  no  missed/skipped  deadlines: 


Experiment:  EXPERIMEIT_1  HARMOVIC 

Completion  on:  Miss/skip  50  deadlines 

Ram  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS):  1336.78 
Test  24  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

■o. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  x 

2 

4.00 

16 

64.00 

4.79  X 

3 

8.00 

8 

64.00 

4.79  X 

4 

16.00 

4 

64.00 

4.79  X 

5 

400.00 

2 

800.00 

59.85  X 

1056.00 

79.00  X 

Experiment  step  size:  2.39  % 


Test  24  results: 

Test  duration  (seconds):  10.0 

Task  Period  Met 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

250.000 

40 

0 

0 

0.000 

3 

125.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

2.500 

4001 

0 

0 

0.000 

02 


Test  when  deadlines  first  missed/skipped: 


Experiment 

EXPERIMEVT.l  HARMOVIC 

Completion  on:  Niss/skip  50  deadlines 

Ram  speed  in  Kilo-Whet stone  Instructions  Per  Second  (KWIPS) :  1336.78 

Test  25  characteristics: 

Task  Frequency  Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  7. 

2 

4.00 

16 

64.00 

4.79  % 

3 

8.00 

8 

64.00 

4.79  X 

4 

16.00 

4 

64.00 

4.79  y. 

5 

416.00 

2 

832.00 

62.24  X 

Experiment 

step  size: 

2.39  X 

1088.00 

81.39  X 

Test  25 

result 8: 

Test  duration  (seconds):  10.0 

Task 

Period 

Met 

Missed 

Skipped 

Average 

Ho. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

0 

10 

10 

472.650 

2 

250.000 

40 

0 

0 

0.000 

3 

126.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

2.404 

4158 

1 

1 

0.061 

Final  test  performed : 


Experiment :  EXPERIMEVT.l  HARMOVIC 


Completion  on:  Miss/ekip  50  deadlines 

Raw  speed  in  Kilo-Whet stone  Instructions  Per  Second  (KWIPS):  1336.78 
Test  26  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  % 

2 

4.00 

16 

64.00 

4.79  y. 

3 

8.00 

8 

64.00 

4.79  y. 

4 

16.00 

4 

64.00 

4.79  y. 

5 

432.00 

2 

864.00 

64.63  % 

1120.00 

83.78  % 

Experiment 

step  size: 

2.39  % 

Test  26 

results : 

Test  duration  (seconds):  10.0 

Task 

Period 

Met 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

600.000 

0 

7 

13 

791.190 

2 

250.000 

4 

18 

18 

79.376 

3 

125.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

2.315 

4314 

3 

3 

0.163 

Benchmark  :  Hart stone  Benchmark,  Version  1.0 

Compiler  :  System  Designers  XD  Ada  MC68020  Ver  1.0,  Kernel  Ver  V1.2A-33 
Target  :  MVME133A-20  32-bit  Monoboard  Microcomputer  (68020  C  20.0  MHz) 

Characteristics  o f  best  test  for  this  experiment: 

(no  missed/skipped  deadlines) 

Test  24  of  Experiment  1  Harmonic 

Raw  (non-tasking)  benchmark  speed  in  KWIPS:  1336.78 

Full  task  set: 
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Total 

Tasks 

S 


Deadlines 
Per  Second 
430.00 


Task  Set  Total 

Utilization  KVIPS 

79.00  54  10S6.00 


Highest-! requency  task : 


Period  Deadlines 

(msec)  Per  Second 

2.500  400.00 


Task  Task 

Utilization  KVIPS 

59.85  X  800.00 


Experiment  step  size:  2.39  % 


EID  OF  HARTSTOIE  BE1CHMARK  SUMMARY  RESULTS 


C.1.2  RATESIM  Results  -  Experiment  1 


C.  1.2.1  Successful  Scheduling 


I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 


Enter  choice:  g 

Enter  file  name  to  get  the  task  set  from:  expl.pass 

Execution 

Task  name  Time(us)  Period (us) /Frequency (Hz)  Deadline(us) 


Task  5 

Rendezvous 

1496 

:  none 

2458 

/ 

406.83 

2458 

Task  4 

Rendezvous 

2992 

:  none 

62500 

/ 

16.00 

62500 

Task  3 

Rendezvous 

5984 

:  none 

125000 

/ 

8.00 

125000 
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Task  2 

Rendezvous 

11969 

:  none 

2S0000 

/ 

4.00 

250000 

Task  1 

Rendezvous 

23938 

:  none 

500000 

/ 

2.00 

500000 

I  Rate  Monotonic  Scheduler  Model | 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  p 


2  -  Remove  task  3  -  Get  from  file 

6  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 


Enter  length  of  simulation  in  microseconds:  10.000.000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 

Cumulative  Execution.Time  (us) : 

6086302 

Deadlines  Met  : 

4068 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

268 

Worst  case  blocking  time  in  a  single  period  (us): 

922 

Cumulative  early  deadlines  (us): 

2209876.00 

Context  Switches  : 

4336 

Delay  Expirations  : 

4068 

Task  Statistics  for  task  :  Task  4 

Cumulative  Bxecution_Time  (us):  478720 
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Task  Statistics  lor  task  :  Task  1 


Cumulative  Execution_Time  (us) :  478760 
Deadlines  Net  :  20 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1076 
Worst  case  blocking  time  in  a  single  period  (us): 

99178 

Cumulative  early  deadlines  (us):  87792.00 
Context  Switches  :  1096 
Delay  Expirations  :  19 


Simulation  Time  (us):  10000058 
User  Cumulative  Task  Execution  Time  (us) :  8001262 
User  Deadlines  Met  :  4368 
User  Deadlines  Missed  :  0 
Context  Switches  :  8750 
Delay  Expirations  :  4364 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  405446 
System  Task  Execution  Time  (us):  1977526 
Idle  Time  (us):  21270 
Percentage  User  Task  Execution  Time  :  80.012156 
Percentage  System  Task  Execution  :  19.775145 
Percentage  Idle  Time  :  0.212699 


C.l.2.2  Scheduling  Failure-  Experiment  1 


I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 

2 

-  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5 

-  Perform  simulation 

6  -  Rate  Monotonic  Theorem 

7  -  Edit  task 

8 

-  Display  tasks 

9  -  Quit 

Enter  choice:  g 

Enter  file  name  to  get  the  task  set  from:  expl.fail 

Execution 
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Task  name 


Time (us)  Period (us) /Frequency (Hz)  Deadline(us) 


Task  5 

Rendezvous 

1496 

:  none 

Task  4 

Rendezvous 

2992 

:  none 

Task  3 

Rendezvous 

5984 

:  none 

Task  2 

Rendezvous 

11969 

:  none 

Task  1 

Rendezvous 

23938 

:  none 

2457 

/ 

407.00 

2457 

62500 

/ 

16.00 

62500 

125000 

/ 

8.00 

125000 

250000 

/ 

4.00 

250000 

500000 

/ 

2.00 

500000 

I  Rate  Nonotonic  Scheduler  Model! 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Nonotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 


Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution_Time  (us):  6088720 
Deadlines  Net  :  4068 
Deadlines  Missed  :  2 
First  deadline  missed  at  :  4501224 
Execution  completed  at  :  4501307 
Cumulative  late  deadlines  (us):  154.00 


Preemptions  suffered  due  to  higher 
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274 


priority  user  tasks  or  system  tasks  : 

Horst  case  blocking  time  in  a  single  period  (us) : 

1044 

Cumulative  early  deadlines  (us):  221S230.00 

Context  Snitches  :  4342 

Delay  Expirations  :  4067 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us) :  478720 
Deadlines  Net  :  160 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  967 
Horst  case  blocking  time  in  a  single  period  (us): 

3833 

Cumulative  early  deadlines  (us):  7466530.00 
Context  Snitches  :  1127 
Delay  Expirations  :  169 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution_Time  (us):  478720 
Deadlines  Net  :  80 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1037 
Horst  case  blocking  time  in  a  single  period  (us): 

9554 

Cumulative  early  deadlines  (us):  6253632.00 
Context  Snitches  :  1117 
Delay  Expirations  :  79 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution.Time  (us):  478760 
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Deadlines  Net  :  40 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1025 
Worst  case  blocking  time  in  a  single  period  (us) : 

24664 

Cumulative  early  deadlines  (us):  5053884.00 
Context  Switches  :  1065 
Delay  Expirations  :  39 


Task  Statistics  for  task  :  Task  1 


Cumulative  Execution.Time  (us) :  478760 
Deadlines  Met  :  20 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1091 
Worst  case  blocking  time  in  a  single  period  (us): 

98981 

Cumulative  early  deadlines  (us):  66821.00 
Context  Snitches  :  1111 
Delay  Expirations  :  19 


======= 


Simulation  Time  (us) :  10000001 
User  Cumulative  Task  Execution  Time  (us):  8003680 
User  Deadlines  Met  :  4368 
User  Deadlines  Missed  :  2 
Context  Snitches  :  8760 
Delay  Expirations  :  4363 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  396314 
System  Task  Execution  Time  (us):  1978702 
Idle  Time  (us):  17611 
Percentage  User  Task  Execution  Time  :  80.036792 
Percentage  System  Task  Execution  :  19.787018 
Percentage  Idle  Time  :  0.176110 
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C.1.2.S  Scheduling  Failure  -  Experiment  l(Hartstone  Benchmark  Task  Parameters ) 
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1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  g 


Enter  file  name  to 


Task  name 


Task  5 

Rendezvous 


Task  4 

Rendezvous 


Task  3 

Rendezvous 


Task  2 

Rendezvous 


Task  1 

Rendezvous 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 


(Rate  Nonotonic  Scheduler  Nodell 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Nonotonic  Theorem 

8  -  Display  tasks  9  -  Quit 


get  the  task  set  from:  expl.f ail. hart 
Execution 

Time(us)  Period(us)/Frequency(Hz)  Deadline(us) 


1496 

:  none 

2404 

/ 

415 . 97 

2404 

2992 

:  none 

62500 

/ 

16.00 

62500 

5984 

:  none 

126000 

/ 

8.00 

125000 

11969 

:  none 

250000 

/ 

4.00 

250000 

23938 

:  none 

500000 

/ 

2.00 

500000 

I  Rate  Nonotonic  Scheduler  Nodell 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Nonotonic  Theorem 

8  -  Display  tasks  9  -  Quit 


Enter  choice:  p 


Enter  length  of  simulation  in  microseconds : 10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  S 


Cumulative  Execution.Time  (us) :  6223360 
Deadlines  Met  :  4159 
Deadlines  Missed  :  1 
First  deadline  missed  at  :  8688056 
Execution  completed  at  :  8688063 
Cumulative  late  deadlines  (us):  7.00 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  192 
Worst  case  blocking  time  in  a  single  period  (us): 

804 

Cumulative  early  deadlines  (us):  2010855.00 
Context  Switches  :  4351 
Delay  Expirations  :  4158 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution.Time  (us):  478896 
Deadlines  Met  :  160 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1065 
Worst  case  blocking  time  in  a  single  period  (us): 

4196 

Cumulative  early  deadlines  (us):  7297544.00 
Context  Switches  :  1225 
Delay  Expirations  :  160 


Task  Statistics  for  task  :  Task  3 

Cumulative  Execution_Time  (us): 
Deadlines  Met  : 

Deadlines  Missed  : 

Preemptions  suffered  due  to  higher 


478720 

80 

0 


C-13 


1139 


priority  user  tasks  or  system  tasks  : 

Worst  case  blocking  time  in  a  single  period  (us) : 

10372 

Cumulative  early  deadlines  (us):  5972978.00 

Context  Switches  :  1219 

Delay  Expirations  :  80 


Cumulative  Execution_Time  (us) :  478760 
Deadlines  Met  :  40 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1235 
Worst  case  blocking  time  in  a  single  period  (us) : 

42487 

Cumulative  early  deadlines  (us):  2317635.00 
Context  Switches  :  1275 
Delay  Expirations  :  40 


Cumulative  Execution_Time  (us) :  S 

Deadlines  Met  : 

Deadlines  Missed  : 

First  deadline  missed  at  :  ( 

Execution  completed  at  :  1 

Cumulative  late  deadlines  (us) :  19673( 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

Worst  case  blocking  time  in  a  single  period  (us): 

5 

Cumulative  early  deadlines  (us): 

Context  Switches  : 

Delay  Expirations  : 


330520 

0 

13 

500000 

733014 

19673080.00 


153315 

0.00 

863 

0 
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User  Deadlines  Net  :  4439 
User  Deadlines  Missed  :  14 
Context  Snitches  :  8919 
Delay  Expirations  :  4438 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  474816 
System  Task  Execution  Time  (us) :  2010443 
Idle  Time  (us) :  0 
Percentage  User  Task  Execution  Time  :  79.896S28 
Percentage  System  Task  Execution  :  20.102912 
Percentage  Idle  Time  :  0.000000 


C.l.S  Hartstone  Results  -  Experiment  2 


HARTSTOIE  BE1CHMARK  SUMMARY  RESULTS 


Baseline  test: 


Experiment:  EXPERIMEVT.2  HARM0IIC 

Completion  on:  Miss/skip  50  deadlines 

Ran  speed  in  Kilo-Vhetstone  Instructions  Per  Second  (KVIPS):  1336.80 
Test  1  characteristics: 


Task 

Frequency 

Kilo-Vhets 

Kilo-Vhets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  X 

2 

4.00 

16 

64.00 

4.79  X 

3 

8.00 

8 

64.00 

4.79  X 

4 

16.00 

4 

64.00 

4.79  X 

5 

32.00 

2 

64.00 

4.79  X 

320.00 

23.94  X 

Experiment  step  size:  2.39  % 


Test  1  results: 

Test  duration  (seconds):  10.0 
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Task 

Period 

Net 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

250.000 

40 

0 

0 

0.000 

3 

125.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

31.250 

320 

0 

0 

0.000 

Last  test  with  no  missed/skipped  deadlines: 


Experiment:  EXPERIME9T.2  HARM01IC 

Completion  on:  Miss/skip  50  deadlines 

Ran  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.80 
Test  29  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

7.60 

32 

243.20 

18.19  7. 

2 

15.20 

16 

243.20 

18.19  7. 

3 

30.40 

8 

243.20 

18.19  7. 

4 

60.80 

4 

243.20 

18.19  % 

5 

121.60 

2 

243.20 

18.19  7. 

1216.00 

90.96  7. 

Experiment  step  size:  2.39  % 


Test  29  results: 


Test  duration  (seconds):  10.0 


Task 

Period 

Net 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

131.579 

76 

0 

0 

0.000 

2 

65.789 

152 

0 

0 

0.000 

3 

32.895 

304 

0 

0 

0.000 

4 

16.447 

608 

0 

0 

0.000 

5 

8.224 

1216 

0 

0 

0.000 
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Test  when  deadlines  first  missed/skipped: 


Experiment :  EXPERIMEJT_2  HARMOIIC 

Completion  on:  Niss/skip  50  deadlines 

Raw  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS):  1336.80 
Test  30  characteristics : 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

7.80 

32 

249.60 

18.67  X 

2 

15.60 

16 

249.60 

18.67  y. 

3 

31.20 

8 

249.60 

18.67  X 

4 

62.40 

4 

249.60 

18.67  % 

5 

124.80 

2 

249.60 

18.67  % 

Experiment 

step  size: 

2.39  X 

1248.00 

93.36  X 

Test  30 

results : 

Test  duration  (seconds):  10.0 

Task 

Period 

Net 

Hissed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

128.205 

1 

39 

39 

49.521 

2 

64.103 

157 

0 

0 

0.000 

3 

32.051 

313 

0 

0 

0.000 

4 

16.026 

625 

0 

0 

0.000 

5 

8.013 

1249 

0 

0 

0.000 

Final  test  performed: 

See  preceding  summary  of  test  30 


Benchmark  :  Hartstone  Benchmark,  Version  1.0 

Compiler  :  System  Designers  XD  Ada  MC68020  Ver  1.0,  Kernel  Ver  V1.2A-33 
Target  :  MVME133A-20  32-bit  Monoboard  Microcomputer  (68020  #20.0  MHz) 

Characteristics  of  best  test  for  this  experiment: 

(no  missed/skipped  deadlines) 

Test  29  of  Experiment  2  Harmonic 

Rau  (non-tasking)  benchmark  speed  in  KVIPS:  1336.80 
Full  task  set: 


Total  Deadlines 

Tasks  Per  Second 

5  235.60 


Task  Set  Total 

Utilization  KVIPS 

90.96  1,  1216.00 


Highest-lrequency  task : 


Period 

(msec) 

8.224 


Deadlines  Task 

Per  Second  Utilization 
121.60  18.19  Y. 


Task 

KVIPS 

243.20 


Experiment  step  size:  2.39  % 


EHD  OF  HARTSTOIE  BEICHMARK  SUMMARY  RESULTS 


C.1.4  RATESIM  Results  -  Experiment  2 


C.  1.4.1  Successful  Scheduling 


I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 
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Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  ezp2_pass 

Execution 

Task  name  Time (us)  Period(us)/Frequency(Hz)  Deadline(us) 


Task  5 

Rendezvous 

1496 

:  none 

8123 

/ 

123.11 

8123 

Task  4 

Rendezvous 

2992 

:  none 

16246 

/ 

61.55 

16246 

Task  3 

Rendezvous 

S984 

:  none 

32492 

/ 

30.78 

32492 

Task  2 

Rendezvous 

11969 

:  none 

64984 

/ 

15.39 

64984 

Task  1 

Rendezvous 

23938 

:  none 

129968 

/ 

7.69 

129968 

I  Rate  Monotonic  Scheduler  Model I 


Add  task 

2  -  Remove  task 

3  -  Get  from  file 

Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Monotonic  Theorem 

Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 


Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  ExecutionJFime  (us): 
Deadlines  Met  : 

Deadlines  Missed  : 


C-19 


1843072 

1232 

0 


61 


Pr adaptions  suffered  due  to  higher 

priority  user  tasks  or  systea  tasks  : 

Worst  case  blocking  time  in  a  single  period  (us) : 

648 


Cumulative  early  deadlines 

(us) : 

7681009.00 

Context  Snitches  : 

1283 

Delay  Expirations  : 

1231 

Task  Statistics  for  task  : 

Task  4 

Cumulative  Execution.Time  (us):  1843072 
Deadlines  Met  :  616 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  47 
Worst  case  blocking  time  in  a  single  period  (us) : 

681 

Cumulative  early  deadlines  (us):  6907093.00 
Context  Snitches  :  663 
Delay  Expirations  :  616 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution_Time  (us):  1843072 
Deadlines  Met  :  308 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  systea  tasks  :  363 
Worst  case  blocking  tiae  in  a  single  period  (us): 

1333 

Cumulative  early  deadlines  (us):  6961615.00 
Context  Snitches  :  661 
Delay  Expirations  :  307 


Task  Statistics  for  task  :  Task  2 
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Cumulative  Execution.Time  (us) :  1843226 
Deadlines  Net  :  154 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  355 
Worst  case  blocking  time  in  a  single  period  (us) : 

2506 

Cumulative  early  deadlines  (us):  5023971.00 
Context  Seitches  :  509 
Delay  Expirations  :  153 


Task  Statistics  for  task  :  Task  1 


Cumulative  Execution.Time  (us):  1843226 
Deadlines  Net  :  77 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  587 
Worst  case  blocking  time  in  a  single  period  (us) : 

10151 

Cumulative  early  deadlines  (us):  23088.00 
Context  Switches  :  664 
Delay  Expirations  :  76 


Simulation  Time  (us):  10007547 
User  Cumulative  Task  Execution  Time  (us):  9215668 
User  Deadlines  Net  :  2387 
User  Deadlines  Missed  :  0 
Context  Switches  :  3780 
Delay  Expirations  :  2382 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  217918 
System  Task  Execution  Time  (us) :  767168 
Idle  Time  (us):  24711 
Percentage  User  Task  Execution  Time  :  92.087182 
Percentage  System  Task  Execution  :  7.665895 
Percentage  Idle  Time  :  0.246924 
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C. I.4.2  Scheduling  Failure 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  g 

Enter  file  name  to 

Task  name 


Task  5 

Rendezvous 


Task  4 

Rendezvous 


Task  3 

Rendezvous 


Task  2 

Rendezvous 


Task  1 

Rendezvous 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 


I  Rate  Monotonic  Scheduler  Model I 


2  -  Remove  task 
5  -  Perform  simulation 
8  -  Display  tasks 


3  -  Get  from  file 
6  -  Rate  Monotonic  Theorem 
9  -  Quit 


get  the  task  set  from:  exp2_fail 
Execution 

Time(us)  Period(us) /Frequency (Hz)  Deadline(us) 


1496 

none 

8122 

/ 

123.12 

8122 

2992 

none 

16244 

/ 

61.56 

16244 

6984 

none 

32488 

/ 

30.78 

32488 

11969 

none 

64976 

/ 

15.39 

64976 

23938 

none 

129952 

/ 

7.70 

129952 

I  Rate  Monotonic  Scheduler  Model I 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 
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Enter  choice:  p 


Enter  length  oi  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  lor  task  :  Task  5 


Cumulative  Execution.Time  (us) :  1843072 
Deadlines  Met  :  1232 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  51 
Horst  case  blocking  time  in  a  single  period  (us) : 

616 

Cumulative  early  deadlines  (us):  7677033.00 
Context  Switches  :  1283 
Delay  Expirations  :  1231 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution.Time  (us) :  1843072 
Deadlines  Met  :  616 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  48 
Horst  case  blocking  time  in  a  single  period  (us) : 

807 

Cumulative  early  deadlines  (us):  6904137.00 
Context  Switches  :  664 
Delay  Expirations  :  615 


Task  Statistics  for  Task  :  Task  3 


Cumulative  Execution.Time  (us) : 
Deadlines  Met  : 

Deadlines  Missed  : 

Preemptions  suffered  due  to  higher 


1843072 

308 

0 
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3S5 


priority  user  tasks  or  system  tasks  : 

Worst  case  blocking  time  in  a  single  period  (us): 

1490 

Cumulative  early  deadlines  (us):  5958069.00 

Context  Snitches  :  663 

Delay  Expirations  :  307 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution_Time  (us) :  1843226 
Deadlines  Met  :  154 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  358 
Worst  case  blocking  time  in  a  single  period  (us): 

4051 

Cumulative  early  deadlines  (us):  4980937.00 
Context  Snitches  :  512 
Delay  Expirations  :  153 
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User  Deadlines  Met  :  2386 
User  Deadlines  Missed  :  1 
Context  Snitches  :  3780 
Delay  Expirations  :  2381 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  216923 
System  Task  Execution  Time  (us):  767629 
Idle  Time  (us):  23033 
Percentage  User  Task  Execution  Time  :  92.098345 
Percentage  System  Task  Execution  :  7.671431 
Percentage  Idle  Time  :  0.230184 


C.  1.4-3  Scheduling  Failure  -  Experiment  2(Hartstone  Benchmark  Task  Parameters) 


I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  exp2_f ail. hart 

Execution 

Task  name  Time(us)  Period(us)/Frequency(Hz)  Deadline(us) 


Task  5 

Rendezvous 

1496 

:  none 

8175 

/ 

122.32 

8175 

Task  4 

Rendezvous 

2992 

:  none 

16349 

/ 

61.17 

16349 

Task  3 

Rendezvous 

5984 

:  none 

32699 

/ 

30.58 

32699 

Task  2 

Rendezvous 

11968 

:  none 

65397 

/ 

15.29 

65397 

2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 
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Task  Statistics  lor  task  :  Task  4 


Cumulative  Exscut ion.Time  (us):  1831104 
Deadlines  Met  :  612 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  665 
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Worst  case  blocking  time  in  a  single  period  (ns) : 


Cumulative  early  deadlines  (us) : 
Context  Snitches  : 

Delay  Expirations  : 


1371 
6768S34 . 00 
1177 
611 


Task  Statistics  lor  task  :  Task  3 


Cumulative  Execution.Time  (us):  1831104 
Deadlines  Met  :  306 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  352 
Worst  case  blocking  time  in  a  single  period  (us): 

1691 

Cumulative  early  deadlines  (us):  5940818.00 
Context  Snitches  :  658 
Delay  Expirations  :  305 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution.Time  (us):  1831104 
Deadlines  Met  :  153 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  464 
Worst  case  blocking  time  in  a  single  period  (us): 

5199 

Cumulative  early  deadlines  (us):  3485032.00 
Context  Snitches  :  617 
Delay  Expirations  :  152 


Task  Statistics  for  task  :  Task  1 

Cumulative  ExecutionJTime  (us):  1743755 

Deadlines  Met  :  20 
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Deadlines  Missed  : 

First  deadline  missed  at  : 
Execution  completed  at  : 
Cumulative  late  deadlines  (us): 


52 

2615880 

2615924 

10881108.00 


Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  572 

Horst  case  blocking  time  in  a  single  period  (us): 

19856 

Cumulative  early  deadlines  (us):  18083.00 

Context  Snitches  :  592 

Delay  Expirations  :  20 


Simulation  Time  (us) :  10005702 
User  Cumulative  Task  Execution  Time  (us):  9068171 
User  Deadlines  Met  :  2315 
User  Deadlines  Missed  :  52 
Context  Snitches  :  4268 
Delay  Expirations  :  2311 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  185815 
System  Task  Execution  Time  (us):  919111 
Idle  Time  (us) :  18212 
Percentage  User  Task  Execution  Time  :  90.630033 
Percentage  System  Task  Execution  :  9.185872 
Percentage  Idle  Time  :  0.182016 


C.1.5  Hartstone  Results  -  Experiment  S 


HARTSTOIE  BEICHMARK  SUMMARY  RESULTS 


Baseline  test: 


Experiment:  EXPERIMEVT_3  HARM0VIC 

Completion  on:  Miss/skip  50  deadlines 

Ran  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.80 
Test  1  characteristics: 
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Task 

Frequency 

Kilo-Vhets 

Kilo- Whet s 

Requested  Workload 

Ko. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  X 

2 

4.00 

16 

64.00 

4.79  % 

3 

8.00 

8 

64.00 

4.79  y. 

4 

16.00 

4 

64.00 

4.79  X 

5 

32.00 

2 

64.00 

4.79  X 

320.00 

23.94  X 

Experiment  step  size:  4.64  % 


Test  1  results: 

Test  duration  (seconds):  10.0 


Task 

Period 

Net 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

250.000 

40 

0 

0 

0.000 

3 

125.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

31.260 

320 

0 

0 

0.000 

Last  test  with  no  missed/skipped  deadlines: 


Experiment:  EXPERIHEIT_3  HARHOIIC 

Completion  on:  Miss/skip  50  deadlines 

Raw  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS):  1336.80 
Test  16  characteristics: 


Task 

Frequency 

Kilo-Vhets 

Kilo-Vhets 

Requested  Workload 

Vo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

47 

94.00 

7.03  X 

2 

4.00 

31 

124.00 

9.28  y. 

3 

8.00 

23 

184.00 

13.76  X 

4 

16.00 

19 

304.00 

22.74  X 

5 

32.00 

17 

544.00 

40.69  X 

1250.00 

93.51  X 
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Experiment  step  size:  4.64  % 


Test  16  results: 

Test  duration  (seconds):  10.0 


Task 

Period 

Met 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

250.000 

40 

0 

0 

0.000 

3 

125.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

31.250 

320 

0 

0 

0.000 

Test  vhen  deadlines  first  missed/skipped: 


Experiment:  EXPERIME*T_3  HARMOIIC 

Completion  on:  Miss/skip  50  deadlines 

Ram  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.80 
Test  17  characteristics: 


Task 

Frequency 

Kilo-Hhets 

Kilo-Whets 

Requested  Workload 

Vo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

48 

96.00 

7.18  X 

2 

4.00 

32 

128.00 

9.58  X 

3 

8.00 

24 

192.00 

14.36  X 

4 

16.00 

20 

320.00 

23.94  X 

5 

32.00 

18 

576 . 00 

43.09  X 

1312.00 

98.14  X 

Experiment  step  size:  4.64  % 


Test  17  results: 


Test  duration  (seconds):  10.0 


Task 

lo. 


Period 

in  msecs 


Met 

Deadlines 


Missed 

Deadlines 


Skipped  Average 
Deadlines  Late  (msec) 
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1 

500.000 

0 

10 

10 

234.229 

2 

250.000 

40 

0 

0 

0.000 

3 

125.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

31.250 

320 

0 

0 

0.000 

Final  test  performed: 


Experiment:  EXPERIMEIT_3  HARMOMIC 

Completion  on:  Miss/skip  SO  deadlines 

Ran  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS):  1336.80 
Test  18  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

Vo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

49 

98.00 

7.33  y. 

2 

4.00 

33 

132.00 

9.87  % 

3 

8.00 

25 

200.00 

14.96  y. 

4 

16.00 

21 

336.00 

25.13  % 

5 

32.00 

19 

608.00 

45.48  % 

1374.00 

102.78  y. 

Experiment 

step  size: 

4.64  y. 

Test  18 

results : 

Test  duration  (seconds) 

:  10.0 

Task 

Period 

Net 

Hissed 

Skipped 

Average 

■o. 

in  msecs  Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

0 

5 

15 

1195.361 

2 

250.000 

40 

0 

0 

0.000 

3 

125.000 

80 

0 

0 

0.000 

4 

62.500 

160 

0 

0 

0.000 

5 

31.250 

320 

0 

0 

0.000 

Benchmark  :  Hartstone  Benchmark,  Version  1.0 

Compiler  :  System  Designers  XD  Ada  MC68020  Ver  1.0,  Kernel  Ver  V1.2A-33 
Target  :  MVME133A-20  32-bit  Monoboard  Microcomputer  (68020  t  20.0  MHz) 

Characteristics  of  best  test  lor  this  experiment: 

(no  missed/skipped  deadlines) 

Test  16  of  Experiment  3  Harmonic 

Raw  (non-tasking)  benchmark  speed  in  KVIPS:  1336.80 

Full  task  set: 


Total  Deadlines 

Tasks  Per  Second 

5  62.00 


Task  Set  Total 

Utilization  KVIPS 

93.51  */.  1250.00 


Highest-lrequency  task: 


Period  Deadlines 

(msec)  Per  Second 

31.250  32.00 


Task  Task 

Utilization  KVIPS 

40.69  %  544.00 


Experiment  step  size:  4.64  X 


EID  OF  HARTSTOVE  BENCHMARK  SUMMARY  RESULTS 


C.1.6  RATESIM  Results  -  Experiment  S 


C.  1.6.1  Successful  Scheduling 


I Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Monotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  exp3_pass 

Execution 


Task  name 

Time(us) 

Task  5 

Rendezvous 

13390 

:  none 

Task  4 

Rendezvous 

14886 

:  none 

Task  3 

Rendezvous 

17879 

:  none 

Task  2 

Rendezvous 

23863 

:  none 

Task  1 

Rendezvous 

35832 

:  none 

Period (us) /Frequency (Hz)  Deadline(us) 


31250 

/ 

32.00 

31250 

62500 

/ 

16.00 

62500 

125000 

/ 

8.00 

125000 

250000 

/ 

4.00 

250000 

500000 

/ 

2.00 

500000 

I  Rate  Nonotonic  Scheduler  Nodell 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  p 


2  -  Remove  task 
5  -  Perform  simulation 
8  -  Display  tasks 


3  -  Get  from  file 
6  -  Rate  Nonotonic  Theorem 
9  -  Quit 


Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution.Time  (us) :  4284800 
Deadlines  Net  :  320 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 
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96 


priority  user  tasks  or  system  tasks  : 

Worst  case  blocking  time  in  a  single  period  (ns): 

541 

Cumulative  early  deadlines  (us):  5586668.00 

Context  Snitches  :  416 

Delay  Expirations  :  319 


Task  Statistics  lor  task  :  Task  4 


Cumulative  Execution.Time  (us) :  2381760 
Deadlines  Met  :  160 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  50 
Worst  case  blocking  time  in  a  single  period  (us) : 

682 

Cumulative  early  deadlines  (us):  5380289.00 
Context  Snitches  :  210 
Delay  Expirations  :  159 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution_Time  (us):  1430320 
Deadlines  Met  :  80 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  93 
Worst  case  blocking  time  in  a  single  period  (us): 

1260 

Cumulative  early  deadlines  (us):  5135262.00 
Context  Snitches  :  173 
Delay  Expirations  :  79 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution.Time  (us) :  954520 
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Deadlines  Nat  :  40 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  200 
Horst  case  blocking  time  in  a  single  period  (us) : 

4994 

Cumulative  early  deadlines  (us):  128S730.00 
Context  Switches  :  240 
Delay  Expirations  :  39 


Task  Statistics  for  task  :  Task  1 


Cumulative  Execution.Time  (us):  716640 
Deadlines  Met  :  20 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  100 
Horst  case  blocking  time  in  a  single  period  (us) : 

11469 

Cumulative  early  deadlines  (us):  3307.00 
Context  Switches  :  120 
Delay  Expirations  :  19 


Simulation  Time  (us) :  10000015 
User  Cumulative  Task  Execution  Time  (us):  9768040 
User  Deadlines  Met  :  620 
User  Deadlines  Missed  :  0 
Context  Snitches  :  1169 
Delay  Expirations  :  615 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  40715 
System  Task  Execution  Time  (us):  228211 
Idle  Time  (us):  3764 
Percentage  Use  "ask  Execution  Time  :  97.680253 
Percentage  Syst.  Task  Execution  :  2.282107 
Percentage  Idle  Time  :  0.037640 


C.  1.6.2  Scheduling  Failure  -  Experment  S 
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I  Rate  Monotonic  Scheduler  Model  I 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  g 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 


Enter  file  name  to  get  the  task  set  from:  exp3_fail 

Execution 

Task  name  Time(us)  Period(us)/Frequency(Hz)  Deadline(us) 


Task  5 

Rendezvous 

13398 

:  none 

31250 

/ 

32.00 

31250 

Task  4 

Rendezvous 

14894 

:  none 

62500 

/ 

16.00 

62500 

Task  3 

Rendezvous 

17886 

:  none 

125000 

/ 

8.00 

125000 

Task  2 

Rendezvous 

23870 

:  none 

250000 

/ 

4.00 

250000 

Task  1 

Rendezvous 

35839 

:  none 

500000 

/ 

2.00 

500000 

I  Rate  Monotonic  Scheduler  Model! 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 


Enter  choice:  p 
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Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution.Time  (us) :  4287360 
Deadlines  Met  :  320 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  96 
Worst  case  blocking  time  in  a  single  period  (us) : 

S60 

Cumulative  early  deadlines  (us):  5581655.00 
Context  Switches  :  416 
Delay  Expirations  :  319 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us) :  2383040 
Deadlines  Met  :  160 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  SO 
Worst  case  blocking  time  in  a  single  period  (us) : 

703 

Cumulative  early  deadlines  (us):  5376893.00 
Context  Switches  :  210 
Delay  Expirations  :  159 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution.Time  (us) :  1430880 
Deadlines  Met  :  80 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  93 


Worst  case  blocking  time  in  a  single  period  (us): 

1285 
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Cumulative  early  deadlines  (us) : 
Context  Switches  : 

Delay  Expirations  : 


5132864.00 

173 

79 


Cumulative  Execution_Time  (us):  954800 
Deadlines  Het  :  40 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  200 
Worst  case  blocking  time  in  a  single  period  (us): 

4958 

Cumulative  early  deadlines  (us):  1281429.00 
Context  Switches  :  240 
Delay  Expirations  :  39 


Task  Statistics  for  task  :  Task  1 


Cumulative  Execution.Time  (us) :  715614 
Deadlines  Met  :  1 
Deadlines  Missed  :  18 
First  deadline  missed  at  :  1000000 
Execution  completed  at  :  1218168 
Cumulative  late  deadlines  (us):  4033523.00 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  137 
Worst  case  blocking  time  in  a  single  period  (us) : 

16425 

Cumulative  early  deadlines  (us):  91.00 
Context  Switches  :  138 
Delay  Expirations  :  1 


Simulation  Time  (us) :  10000001 
User  Cumulative  Task  Execution  Time  (us):  9771694 
User  Deadlines  Met  :  601 
User  Deadlines  Missed  :  18 
Context  Switches  :  1159 
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Delay  Expirations  :  597 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  43052 
System  Task  Execution  Time  (us) :  228139 
Idle  Time  (us) :  96 
Percentage  User  Task  Execution  Time  :  97.716930 
Percentage  System  Task  Execution  :  2.281390 
Percentage  Idle  Time  :  0.000960 


C.l.6.8  Scheduling  Failure  -  Experiment  S(Hartstone  Benchmark  Task  Parameters) 


I  Rate  Nonotonic  Scheduler  Model I 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Nonotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  g 


Enter  file  name 

Task  name 

to  get  the  task  set  from:  exp3_f ail. hart 
Execution 

Time(u8)  Period(us)/Frequency(Hz) 

Deadline (us) 

Task  5 

Rendezvous 

13465 

:  none 

31250 

/ 

32.00 

31250 

Task  4 

Rendezvous 

14961 

:  none 

62500 

/ 

16.00 

62500 

Task  3 

Rendezvous 

17953 

:  none 

125000 

/ 

8.00 

125000 

Task  2 

Rendezvous 

23938 

:  none 

250000 

/ 

4.00 

250000 

Task  1 

Rendezvous 

36907 

:  none 

500000 

/ 

2.00 

500000 

C-39 


I  Rata  Monotonic  Scheduler  Model I 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  p 


2  -  Remove  task  3  -  Get  from  file 

S  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 


Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution.Time  (us):  4322265 
Deadlines  Met  :  321 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  96 
Vorst  case  blocking  time  in  a  single  period  (us) : 

614 

Cumulative  early  deadlines  (us):  5571871.00 
Context  Switches  :  417 
Delay  Expirations  :  320 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution.Time  (us) :  2405430 
Deadlines  Met  :  160 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  52 
Horst  cue  blocking  time  in  a  single  period  (us): 

688 

Cumulative  early  deadlines  (us):  5357718.00 
Context  Switches  :  212 
Delay  Expirations  :  160 


Task  Statistics  lor  task  :  Task  3 


Cumulative  Execution.Time  (us) :  1436240 
Deadlines  Met  :  80 
Deadlines  Missed  :  0 
Preemptions  sullered  due  to  higher 

priority  user  tasks  or  system  tasks  :  92 
Worst  case  blocking  time  in  a  single  period  (us): 

1242 

Cumulative  early  deadlines  (us):  5111730.00 
Context  Snitches  :  172 
Delay  Expirations  :  80 


Task  Statistics  lor  task  :  Task  2 


Cumulative  Ezecution.Time  (us):  957520 
Deadlines  Met  :  40 
Deadlines  Missed  :  0 
Preemptions  sullered  due  to  higher 

priority  user  tasks  or  system  tasks  :  238 
Worst  case  blocking  time  in  a  single  period  (us) : 

5432 

Cumulative  early  deadlines  (us):  715452.00 
Context  Snitches  :  278 
Delay  Expirations  :  40 


Task  Statistics  lor  task  :  Task  1 


Cumulative  Execution_Time  (us) :  675469 
Deadlines  Met  :  0 
Deadlines  Missed  :  18 
First  deadline  missed  at  :  500000 
Execution  completed  at  :  734944 
Cumulative  late  deadlines  (us):  7821724.00 


Preemptions  sullered  due  to  higher 
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100 


priority  user  tasks  or  system  tasks  : 

Worst  case  blocking  time  in  a  single  period  (us) : 

16973 

Cumulative  early  deadlines  (us):  0.00 

Context  Switches  :  100 

Delay  Expirations  :  0 


Simulation  Time  (us) :  10025600 
User  Cumulative  Task  Execution  Time  (us):  9796924 
User  Deadlines  Met  :  601 
User  Deadlines  Missed  :  18 
Context  Switches  :  1161 
Delay  Expirations  :  600 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  48005 
System  Task  Execution  Time  (us):  228604 
Idle  Time  (us) :  0 
Percentage  User  Task  Execution  Time  :  97.719079 
Percentage  System  Task  Execution  :  2.280203 
Percentage  Idle  Time  :  0.000000 


C.2  Task  Set  B  -  Nonharmonic 

C.2.1  Hartstone  Results  -  Experiment  1 


HARTSTOVE  BEKCHMARK  SUMMARY  RESULTS 


Baseline  test: 


Experiment:  EXPERIMEIT.l  I0IHARM0IIC 

Completion  on:  Miss/skip  50  deadlines 

Raw  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS):  1336.75 
Test  1  characteristics: 


Task 

lo. 

1 


Frequency 

(Hertz) 

2.00 


Kilo-Whets  Kilo-Whets 
per  period  per  second 
32  64.00 


Requested  Workload 
Utilization 
4.79  X 
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2 

2.30 

16 

36.80 

2.75  y. 

3 

4.59 

8 

36.72 

2.75  X 

4 

6.89 

4 

27.56 

2.06  y. 

5 

9.19 

2 

18.38 

1.37  y. 

183.46 

13.72  X 

Experiment  step  size: 

1.03  ’/. 

Test  1 

results : 

Test  duration  (seconds) 

:  10.0 

Task 

Period 

Net 

Missed 

Skipped 

Average 

lo. 

in  msecs  Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

434.783 

23 

0 

0 

0.000 

3 

217.865 

46 

0 

0 

0.000 

4 

145.138 

69 

0 

0 

0.000 

5 

108.814 

92 

0 

0 

0.000 

Last  test  with  no  missed/skipped  deadlines: 


Experiment :  EXPERIMEIT.l  IOIHARMOIIC 

Completion  on:  Niss/skip  SO  deadlines 

Raw  speed  in  Kilo-Vhetstone  Instructions  Per  Second  (KVIPS) :  1336.75 
Test  58  characteristics: 


Task 

Frequency 

Kilo-Vhets 

lo. 

(Hertz) 

per  period 

1 

2.00 

32 

2 

2.30 

16 

3 

4.59 

8 

4 

6.89 

4 

5 

401.92 

2 

Experiment 

step  size: 

1.03  X 

Kilo-Vhets 

Requested  Workload 

per  second 

Utilization 

64.00 

4.79  X 

36.80 

2.76  X 

36.72 

2.75  X 

27.56 

2.06  X 

803.84 

60.13  X 

968.92 

72.48  X 
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Test  58  results: 


Test  duration  (seconds):  10.0 


Task 

Period 

Net 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

434.783 

23 

0 

0 

0.000 

3 

217.865 

46 

0 

0 

0.000 

4 

145.138 

69 

0 

0 

0.000 

5 

2.488 

4020 

0 

0 

0.000 

Test  when  deadlines  first  missed/skipped: 


Experiment :  EXPERIMEST_1  I0IHARN0IIC 

Completion  on:  Niss/skip  50  deadlines 

Raw  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS) :  1336.75 
Test  59  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  X 

2 

2.30 

16 

36.80 

2.75  X 

3 

4.59 

8 

36.72 

2.75  X 

4 

6.89 

4 

27.56 

2.06  X 

5 

408.81 

2 

817.62 

61.16  X 

982.70 

73.51  X 

Experiment 

step  size: 

1.03  */. 

Test  59 

results : 

Test  duration  (seconds):  10.0 

Task 

Period  Net 

Hissed 

Skipped 

Average 

lo. 

in  msecs  Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

600.000  20 

0 

0 

0.000 

2 

434.783  23 

0 

0 

0.000 

3 

217.865  46 

0 

0 

0.000 
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4  145.138  69  0  0  0.000 

5  2.446  4087  1  1  0.112 


Final  test  performed: 


Experiment :  EXPERIMENT. 1  HOXHARMOIIC 

Completion  on:  Miss/skip  50  deadlines 

Ran  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.75 
Test  64  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  */. 

2 

2.30 

16 

36.80 

2.75  1. 

3 

4.59 

8 

36.72 

2.75  y. 

4 

6.89 

4 

27.56 

2.06  '/. 

5 

443.26 

2 

886.52 

66.32  % 

1051.60 

78.67  */. 

Experiment  step  size: 

1.03  '/. 

Test  64 

results: 

Test  duration  (seconds):  10.0 

Task 

Period 

Met 

Missed 

Skipped 

Average 

lo 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

8 

6 

6 

72.856 

2 

434.783 

23 

0 

0 

0.000 

3 

217.865 

46 

0 

0 

0.000 

4 

145.138 

69 

0 

0 

0.000 

5 

2.256 

4377 

28 

28 

0.078 

Benchmark  :  Hartstone  Benchmark,  Version  1.0 
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Compiler  :  System  Designers  XD  Ada  MC68020  Ver  1.0,  Kernel  Ver  V1.2A-33 
Target  :  MVME133A-20  32-bit  Monoboard  Microcomputer  (68020  C  20.0  MHz) 

Characteristics  of  best  test  for  this  experiment: 

(no  missed/skipped  deadlines) 

Test  58  of  Experiment  1  lonharmonic 

Has  (non-tasking)  benchmark  speed  in  KVIPS:  1336.75 

Full  task  set: 


Total  Deadlines 

Tasks  Per  Second 

5  417.70 

Highest-f requency  task : 

Period  Deadlines 

(msec)  Per  Second 

2.488  401.92 

Experiment  step  size 


Task  Set  Total 

Utilization  KVIPS 

72.48  ‘/,  968.92 

Task  Task 

Utilization  KVIPS 

60.13  %  803.84 


1.03  r. 


EID  OF  HARTSTOXE  BEICHMARK  SUMMARY  RESULTS 


C.2.2  RATESIM  Results  -  Experiment  1 


C.2.2.1  Successful  Scheduling 


I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Monotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  nh.expl.pas 

Execution 

Task  name  Time (us)  Period (us) /Frequency (Hz)  Deadline(us) 
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Task  5 

Rendezvous 

1496 

:  none 

2488 

/ 

401.93 

2488 

Task  4 

Rendezvous 

2992 

:  none 

145138 

/ 

6.89 

145138 

Task  3 

Rendezvous 

5984 

:  none 

217865 

/ 

4.59 

217865 

Task  2 

Rendezvous 

11969 

:  none 

434783 

/ 

2.30 

434783 

Task  1 

Rendezvous 

23938 

:  none 

500000 

/ 

2.00 

500000 

I  Rate  Nonotonic  Scheduler  Nodell 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  p 


2  -  Remove  task 
S  -  Perform  simulation 
8  -  Display  tasks 


3  -  Get  from  file 
6  -  Rate  Honotonic  Theorem 
9  -  Quit 


Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Ezecution.Time  (us):  6012771 

Deadlines  Net  :  4019 

Deadlines  Hissed  :  0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  262 

Worst  case  blocking  time  in  a  single  period  (us): 

975 

Cumulative  early  deadlines  (us):  2322451.00 
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Context  Stitches  : 
Delay  Expirations  : 


4281 

4019 


Task  Statistics  lor  task  :  Task  4 


Cumulative  Execution_Time  (us) :  206448 
Deadlines  Met  :  69 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  411 
Horst  case  blocking  time  in  a  single  period  (us): 

4245 

Cumulative  early  deadlines  (us):  8913869.00 
Context  Stitches  :  480 
Delay  Expirations  :  68 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution_Time  (us):  275264 
Deadlines  Met  :  46 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  539 
Horst  case  blocking  time  in  a  single  period  (us) : 

9153 

Cumulative  early  deadlines  (us):  8365900.00 
Context  Stitches  :  585 
Delay  Expirations  :  45 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution_Time  (us):  275287 
Deadlines  Met  :  23 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  554 
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Worst  case  blocking  time  in  a  single  period  (us) : 

21147 

Cumulative  early  deadlines  (us):  7610084.00 

Context  Switches  :  577 

Delay  Expirations  :  22 


Task  Statistics  lor  task  :  Task  1 


Cumulative  Execution.Time  (us):  478760 
Deadlines  Met  :  20 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  964 
Worst  case  blocking  time  in  a  single  period  (us): 

50186 

Cumulative  early  deadlines  (us):  6233848.00 
Context  Switches  :  984 
Delay  Expirations  :  19 


Simulation  Time  (us) :  10000048 
User  Cumulative  Task  Execution  Time  (us):  7248530 
User  Deadlines  Met  :  4177 
User  Deadlines  Missed  :  0 
Context  Snitches  :  6907 
Delay  Expirations  :  4173 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  379394 
System  Task  Execution  Time  (us) :  1693010 
Idle  Time  (us) :  1058508 
Percentage  User  Task  Execution  Time  :  72.484952 
Percentage  System  Task  Execution  :  16.930019 
Percentage  Idle  Time  :  10.585029 


C.2.2.2  Scheduling  Failure-  Experiment  1 


r  jg 


I  Rate  Nonotonic  Scheduler  Nodell 


1  -  Add  task  2  -  Remove  task  3  -  Get  from  file 

4  -  Save  to  file  &  -  Perform  simulation  6  -  Rate  Nonotonic  Theorem 

7  -  Edit  task  8  -  Display  tasks  9  -  Quit 

Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  nh.expl.fal 

Execution 

Task  name  Time(us)  Period(us)/Frequency(Hz)  Deadline(us) 


Task  5 

Rendezvous 

1496 

:  none 

2487 

/ 

402.09 

2487 

Task  4 

Rendezvous 

2992 

:  none 

145138 

/ 

6.89 

145138 

Task  3 

Rendezvous 

5984 

:  none 

217865 

/ 

4.59 

217865 

Task  2 

Rendezvous 

11969 

:  none 

434783 

/ 

2.30 

434783 

Task  1 

Rendezvous 

23938 

:  none 

500000 

/ 

2.00 

500000 

I  Rate  Honotonic  Scheduler  Nodell 


1  -  Add  task  2  -  Remove  task  3  -  Get  from  file 

4  -  Save  to  file  5  -  Perform  simulation  6  -  Rate  Nonotonic  Theorem 

7  -  Edit  task  8  -  Display  tasks  9  -  Quit 

Enter  choice:  p 


Enter  length  of  simulation  in  microseconds:  10.000.000 
Print  the  Event  History  (y  or  n)  :  n 
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Task  Statistics  lor  task  :  Task  5 


Cumulative  Execution_Time  (us):  6015416 
Deadlines  Net  :  4018 
Deadlines  Missed  :  3 
First  deadline  missed  at  :  1308162 
Execution  completed  at  :  1308231 
Cumulative  late  deadlines  (us):  118.00 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  261 
Worst  case  blocking  time  in  a  single  period  (us) : 

1060 

Cumulative  early  deadlines  (us):  2317596.00 
Context  Switches  :  4279 
Delay  Expirations  :  4017 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us):  206448 
Deadlines  Met  :  69 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  406 
Worst  case  blocking  time  in  a  single  period  (us): 

4280 

Cumulative  early  deadlines  (us):  8936035.00 
Context  Switches  :  475 
Delay  Expirations  :  68 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution.Time  (us) :  275264 

Deadlines  Met  :  46 

Deadlines  Missed  :  0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  548 

Worst  case  blocking  time  in  a  single  period  (us): 

9335 

Cumulative  early  deadlines  (us):  8366943.00 


Context  Snitches  : 
Delay  Expirations  : 


594 

45 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution.Time  (us):  275287 
Deadlines  Met  :  23 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  556 
Worst  case  blocking  time  in  a  single  period  (us): 

21837 

Cumulative  early  deadlines  (us):  7596566.00 
Context  Snitches  :  579 
Delay  Expirations  :  23 


Task  Statistics  for  task  :  Task  1 


Cumulative  Execution_Time  (us) :  478760 
Deadlines  Met  :  20 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  950 
Worst  case  blocking  time  in  a  single  period  (us) : 

50186 

Cumulative  early  deadlines  (us):  6238280.00 
Context  Snitches  :  970 
Delay  Expirations  :  20 


Simulation  Time  (us) :  10000301 
User  Cumulative  Task  Execution  Time  (us):  7251175 
User  Deadlines  Met  :  4176 
User  Deadlines  Missed  :  3 
Context  Snitches  :  6894 
Delay  Expirations  :  4173 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  380368 
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System  Task  Execution  Time  (us) : 

Idle  Time  (us) : 

Percentage  User  Task  Execution  Time  : 
Percentage  System  Task  Execution  : 
Percentage  Idle  Time  : 


1691228 

1057886 

72.509567 

16.911771 

10.578542 


C.2.2.8  Scheduling  Failure  -  Experiment  JfHartstone  Benchmark  Task  Parameters) 


I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 
4  -  Save  to  tile 
7  -  Edit  task 

Enter  choice:  g 


2  -  Remove  task 
5  -  Perform  simulation 
8  -  Display  tasks 


3  -  Get  from  file 
6  -  Rate  Monotonic  Theorem 
9  -  Quit 


Enter  file  name  to  get  the  task  set  from:  nh_expl_fal 

Execution 

Task  name  Time(us)  Period(us)/Frequency(Hz)  Deadline(us) 


Task  5 

Rendezvous 

1496 

:  none 

2446 

/ 

408.83 

2446 

Task  4 

Rendezvous 

2992 

:  none 

145138 

/ 

6.89 

145138 

Task  3 

Rendezvous 

5984 

:  none 

217865 

/ 

4.59 

217865 

Task  2 

Rendezvous 

11969 

:  none 

434783 

/ 

2.30 

434783 

Task  1 

Rendezvous 

23938 

:  none 

500000 

/ 

2.00 

500000 
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I  Rate  Nonotonic  Scheduler  Model I 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  p 


Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  S 


Cumulative  Execution.Time  (us):  6116110 
Deadlines  Met  :  4087 
Deadlines  Missed  :  1 
First  deadline  missed  at  :  4S00640 
Execution  completed  at  :  4E00670 
Cumulative  late  deadlines  (us):  30.00 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  287 
Horst  case  blocking  time  in  a  single  period  (us): 

980 

Cumulative  early  deadlines  (us):  2125119.00 
Context  Switches  :  4374 
Delay  Expirations  :  4087 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us):  206448 
Deadlines  Met  :  69 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  442 
Horst  case  blocking  time  in  a  single  period  (us) : 

4270 

Cumulative  early  deadlines  (us):  8862446.00 
Context  Switches  :  511 
Delay  Expirations  :  68 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 
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Task  Statistics  for  task  :  Task  3 

Cumulative  Execution_Time  (us):  275264 
Deadlines  Net  :  46 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  587 
Worst  case  blocking  time  in  a  single  period  (us): 

9784 

Cumulative  early  deadlines  (us):  8238883.00 
Context  Snitches  :  633 
Delay  Expirations  :  45 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution.Time  (us):  275287 
Deadlines  Met  :  23 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  591 
Worst  case  blocking  time  in  a  single  period  (us): 

23153 

Cumulative  early  deadlines  (us):  7451840.00 
Context  Snitches  :  614 
Delay  Expirations  :  22 


Task  Statistics  for  task  :  Task  1 


Cumulative  Execution_Time  (us):  478760 

Deadlines  Met  :  20 

Deadlines  Missed  :  0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1044 

Worst  case  blocking  time  in  a  single  period  (us): 

64160 

Cumulative  early  deadlines  (us):  5819981.00 


C-55 


Context  Switches  : 
Delay  Expirations  : 


1064 

19 


Simulation  Time  (us):  10000129 
User  Cumulative  Task  Execution  Time  (us) :  7351869 
User  Deadlines  Net  :  4245 
User  Deadlines  Hissed  :  1 
Context  Switches  :  7195 
Delay  Expirations  :  4241 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  447283 
System  Task  Execution  Time  (us) :  1746579 
Idle  Time  (us):  901677 
Percentage  User  Task  Execution  Time  :  73.517742 
Percentage  System  Task  Execution  :  17.465565 
Percentage  Idle  Time  :  9.016654 


C.2.3  Hartstone  Results  -  Experiment  2 


HARTSTOVE  BENCHMARK  SUMMARY  RESULTS 


Baseline  test: 


Experiment:  EXPERIMEVT_2  I0HHARM0IIC 

Completion  on:  Miss/skip  50  deadlines 

Raw  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.75 
Test  1  characteristics: 


Task 

Frequency 

Kilo-Vhets 

No. 

(Hertz) 

per  period 

1 

2.00 

32 

2 

2.30 

16 

3 

4.59 

8 

4 

6.89 

4 

5 

9.19 

2 

Kilo-Whets 

Requested  Workload 

per  second 

Utilization 

64.00 

4.79  X 

36.80 

2.75  X 

36.72 

2.76  X 

27.56 

2.06  X 

18.38 

1.37  X 

183.46 

13.72  X 
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Experiment  step  size:  1.37  X 


Test  1  results: 

Test  duration  (seconds):  10.0 


Task 

Period 

Met 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

S00.000 

20 

0 

0 

0.000 

2 

434.783 

23 

0 

0 

0.000 

3 

217. 86S 

46 

0 

0 

0.000 

4 

145.138 

69 

0 

0 

0.000 

6 

108.814 

92 

0 

0 

0.000 

Last  test  with  no  missed/ skipped  deadlines: 


Experiment :  EXPERIMEIT_2 

Completion  on:  Miss/skip  SO  deadlines 

Ram  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS):  1336.75 
Test  S3  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

12.40 

32 

396.80 

29.68  X 

2 

14.26 

16 

228.16 

17.07  X 

3 

28.46 

8 

227 . 66 

17.03  y. 

4 

42.72 

4 

170.87 

12.78  X 

5 

56.98 

2 

113.96 

8.52  X 

1137.45 

85.09  % 

Experiment  step  size:  1.37  X 


Test  S3  results: 

Test  duration  (seconds):  10.0 

Task  Period  Met  Missed  Skipped  Average 
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lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

80.645 

125 

0 

0 

0.000 

2 

70.126 

143 

0 

0 

0.000 

3 

35.139 

285 

0 

0 

0.000 

4 

23.409 

428 

0 

0 

0.000 

5 

17.551 

570 

0 

0 

0.000 

Test  vhen  deadlines  first  missed/ skipped: 

Experiment 

EXPERIMEVT_2  I0IHARM0IIC 

Completion 

on:  Niss/skip  50  deadlines 

Ram  speed  : 

in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS) :  1336.75 

Test  52  characteristics: 

Task  Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

12.20 

32 

390.40 

29.21  % 

2 

14.03 

16 

224.48 

16.79  y. 

3 

28.00 

8 

223.99 

16.76  % 

4 

42  03 

4 

168 . 12 

12.58  y. 

5 

56.06 

2 

112.12 

8.39  % 

1119.11 

83.72  X 

Experiment 

step  size: 

1.37  y. 

Test  52 

results: 

Test  duration  (seconds):  10.0 

Task 

Period  Met 

Missed 

Skipped 

Average 

Vo. 

in  msecs  Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

81.967  121 

1 

1 

7.751 

2 

71.276  141 

0 

0 

0.000 

3 

35.716  280 

0 

0 

0.000 

4 

23.793  421 

0 

0 

0.000 

5 

17.838  561 

0 

0 

0.000 
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Final  test  performed : 


Experiment 

EXPERIMEXT_2  I0IHARM0IIC 

Completion 

on:  Miss/skip  50  deadlines 

Has  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS):  1336.75 

Test  57  characteristics: 

Task  Frequency 

Kilo- Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

13.20 

32 

422.40 

31.60  X 

2 

15.18 

16 

242 . 88 

18.17  X 

3 

30.29 

8 

242.35 

18.13  y. 

4 

45.47 

4 

181.90 

13.61  y. 

5 

60.65 

2 

121.31 

9.07  X 

1210.84 

90.58  X 

Experiment 

step  size: 

1.37  y. 

Test  57  results: 


Test  duration  (seconds):  10.0 

Task 

Period 

Met 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

76.768 

72 

30 

30 

11.485 

2 

65.876 

162 

0 

0 

0.000 

3 

33.010 

303 

0 

0 

0.000 

4 

21.991 

455 

0 

0 

0.000 

5 

16.487 

607 

0 

0 

0.000 

Benchmark 

:  Hart stone 

Benchmark , 

Version  1.0 

Compiler  :  System  Designers  ZD  Ada  MC68020  Ver  1.0,  Kernel  Ver  V1.2A-33 
Target  :  KVME133A-20  32-bit  Monoboard  Microcomputer  (68020  •  20.0  MHz) 

Characteristics  of  best  test  for  this  experiment: 

(no  missed/ skipped  deadlines) 
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Test  S3  of  Experiment  2  lonharmonic 

Raw  (non-tasking)  benchmark  speed  in  KVIPS:  1336.75 

Full  task  set: 


Total  Deadlines 

Tasks  Per  Second 

5  154.81 


Task  Set  Total 

Utilization  KVIPS 

85.09  %  1137.45 


Highest -frequency  task: 


Period  Deadlines 

(nsec)  Per  Second 

17.551  56.98 


Task  Task 

Utilization  KVIPS 

8.52  %  113.96 


Experiment  step  size:  1.37  % 


EVD  OF  HARTSTOIE  BENCHMARK  SUMMARY  RESULTS 


C.2-4  RATESIM  Results  -  Experiment  2 


C. 2-4-1  Successful  Scheduling 


I  Rate  Monotonic  Scheduler  Model! 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  g 

Enter  file  name  to  get  the  task  set  from:  nh_exp2.pass 

Execution 

Task  name  Time(us)  Period (us) /Frequency (Hz)  Deadline(us) 


Task  5  1496  17135  /  58.36  17135 

Rendezvous  :  none 


2  -  Remove  task 
5  -  Perform  simulation 
8  -  Display  tasks 


3  -  Get  from  file 
6  -  Rate  Monotonic  Theorem 
9  -  Quit 
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Task  4 

2992 

Rendezvous 

:  none 

Task  3 

5984 

Rendezvous 

:  none 

Task  2 

11969 

Rendezvous 

:  none 

Task  1 

23938 

Rendezvous 

:  none 

22852 

/ 

43.76 

22852 

34305 

/ 

29.15 

34305 

68446 

/ 

14.61 

68446 

78740 

/ 

12.70 

78740 

I  Rate  Monotonic  Scheduler  Model  I 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Monotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 


Enter  length  of  simulation  in  microseconds:  10.000.000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution.Time  (us) :  873664 
Deadlines  Met  :  584 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  189 
Worst  case  blocking  time  in  a  single  period  (us) : 

1267 

Cumulative  early  deadlines  (us):  8852982.00 
Context  Switches  :  773 
Delay  Expirations  :  583 
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Task  Statistics  lor  task  :  Task  4 


Cumulative  Execution_Time  (us) : 

1310496 

Deadlines  Net  : 

438 

Deadlines  Hissed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

97 

Worst  case  blocking  time  in  a  single  period  (us): 

Cumulative  early  deadlines  (us) : 

1218 

8375303.00 

Context  Snitches  : 

535 

Delay  Expirations  : 

437 

Cumulative  Execution_Time  (us):  1747328 
Deadlines  Net  :  292 
Deadlines  Nissed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  166 
Worst  case  blocking  time  in  a  single  period  (us): 

1886 

Cumulative  early  deadlines  (us):  7638389.00 
Context  Snitches  :  458 
Delay  Expirations  :  291 


Cumulative  Execution.Time  (us) :  1752421 

Deadlines  Net  :  146 

Deadlines  Nissed  :  0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  359 

Worst  case  blocking  time  in  a  single  period  (us): 

3217 

Cumulative  early  deadlines  (us):  6481774.00 

Context  Snitches  :  505 
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Delay  Expirations  : 


146 


Task  Statistics  lor  task  :  Task  1 


Cumulative  Execution.Time  (us) :  3040126 
Deadlines  Net  :  127 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  721 
Vorst  case  blocking  time  in  a  single  period  (us): 

5363 

Cumulative  early  deadlines  (us):  2111842.00 
Context  Switches  :  848 
Delay  Expirations  :  126 


Simulation  Time  (us) :  10000091 
User  Cumulative  Task  Execution  Time  (us):  8724035 
User  Deadlines  Net  :  1587 
User  Deadlines  Hissed  :  0 
Context  Switches  :  3119 
Delay  Expirations  :  1583 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  127663 
System  Task  Execution  Time  (us) :  716478 
Idle  Time  (us):  559578 
Percentage  User  Task  Execution  Time  :  87.239556 
Percentage  System  Task  Execution  :  7.164715 
Percentage  Idle  Time  :  5.595729 


C.2.4.B  Scheduling  Failure-  Experiment  2 


I  Rate  Nonotonic  Scheduler  Nodell 


1  -  Add  task 


2  -  Remove  task  3  -  Get  from  file 


G-bd 


4  -  Save  to  file 
7  -  Edit  task 


5  -  Perform  simulation 
8  -  Display  tasks 


6  -  Rate  Nonotonic  Theorem 
9  -  Quit 


Enter  choice:  p 


Enter  file  name  to  get  the  task  set  from:  nh_exp2.fail 

Execution 

Task  name  Time(us)  Period(us)/Frequency(Hz)  Deadline(us) 


Task  5 

Rendezvous 

1496 

:  none 

17068 

/ 

58.59 

17068 

Task  4 

Rendezvous 

2992 

:  none 

22763 

/ 

43.93 

22763 

Task  3 

Rendezvous 

5984 

:  none 

34165 

/ 

29.27 

34165 

Task  2 

Rendezvous 

11969 

:  none 

68166 

/ 

14.67 

68166 

Task  1 

Rendezvous 

23938 

:  none 

78431 

/ 

12.75 

78431 

I  Rate  Nonotonic  Scheduler  Nodell 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Nonotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 

Enter  length  of  simulation  in  microseconds:  10.000.000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  S 


C-64 


Cumulative  Execution.Time  (us):  876656 
Deadlines  Met  :  586 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  195 
Worst  case  blocking  time  in  a  single  period  (us) : 

1288 

Cumulative  early  deadlines  (us):  8836499.00 
Context  Switches  :  781 
Delay  Expirations  :  585 


Cumulative  Execution.Time  (us) :  1316480 
Deadlines  Met  :  440 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  114 
Worst  case  blocking  time  in  a  single  period  (us) : 

n75 

Cumulative  early  deadlines  (us):  8361433.00 
Context  Switches  :  554 
Delay  Expirations  :  439 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution.Time  (us) :  1753312 
Deadlines  Met  :  293 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  109 
Worst  case  blocking  time  in  a  single  period  (us): 

1943 

Cumulative  early  deadlines  (us):  7719816.00 
Context  Switches  :  402 
Delay  Expirations  :  292 
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Task  Statistics  for  task  :  Task  2 


Cumulative  Execution_Time  (us):  3057874 
Deadlines  Het  :  126 
Deadlines  Missed  :  1 
First  deadline  missed  at  :  2196068 
Execution  completed  at  :  2207724 
Cumulative  late  deadlines  (us):  11656.00 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  804 
Worst  case  blocking  time  in  a  single  period  (us): 

6827 

Cumulative  early  deadlines  (us):  2010660.00 
Context  Snitches  :  930 
Delay  Expirations  :  126 


Simulation  Time  (us):  10001962 
User  Cumulative  Task  Execution  Time  (us):  8763765 
User  Deadlines  Met  :  1592 
User  Deadlines  Missed  :  1 
Context  Snitches  :  3119 
Delay  Expirations  :  1588 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  139227 
System  Task  Execution  Time  (us) :  716653 
Idle  Time  (us):  521540 
Percentage  User  Task  Execution  Time  :  87.620459 
Percentage  System  Task  Execution  :  7.165124 


Percentage  Idle  Time  : 


B . 214377 


C.2.4-3  Scheduling  Failure  -  Experiment  2(Hartstone  Benchmark  Task  Parameters) 


iRate  Monotonic  Scheduler  Model 1 

1  -  Add  task 

2  -  Remove  task 

3  - 

Get 

from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  - 

Rate 

Monotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  - 

Quit 

Enter  choice: 

Enter  file  name  to 

get  the  task  set  from:  nh_exp2_f ail. hart 

Execution 

Task  name 

Time(us) 

Per iod (us ) /Frequency (Hz ) 

Deadline (us) 

Task  5 

1496 

17838  / 

56.06 

17838 

Rendezvous 

:  none 

Task  4 

2992 

23793  / 

42.03 

23793 

Rendezvous 

:  none 

Task  3 

5984 

35716  / 

28.00 

35716 

Rendezvous 

:  none 

Task  2 

11969 

71276  / 

14.03 

71276 

Rendezvous 

:  none 

Task  1 

23938 

81967  / 

12.20 

81967 

Rendezvous 

:  none 

IRate  Monotonic  Scheduler  Model I 
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1  -  Add  task  2  -  Remove  task  3  -  Get  from  file 

4  -  Save  to  file  5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

7  -  Edit  task  8  -  Display  tasks  9  -  Quit 

Enter  choice:  p 


Enter  length  of  simulation  in  microseconds:  10.000.000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution.Time  (us) :  839256 
Deadlines  Met  :  561 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  140 
Worst  case  blocking  time  in  a  single  period  (us) : 

1070 

Cumulative  early  deadlines  (us):  8899834.00 
Context  Switches  :  701 
Delay  Expirations  :  560 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us):  1259632 
Deadlines  Met  :  421 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  126 
Worst  case  blocking  time  in  a  single  period  (us): 

1224 

Cumulative  early  deadlines  (us):  8410000.00 
Context  Switches  :  547 
Delay  Expirations  :  420 


Task  Statistics  for  task  :  Task  3 
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Cumulative  Execution_Time  (us):  1675520 
Deadlines  Met  :  280 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  98 
Horst  case  blocking  time  in  a  single  period  (us) : 

1769 

Cumulative  early  deadlines  (us):  7804659.00 
Context  Switches  :  378 
Delay  Expirations  :  279 


Cumulative  Execution_Time  (us) :  1687629 
Deadlines  Met  :  141 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  435 
Horst  case  blocking  time  in  a  single  period  (us): 

3231 

Cumulative  early  deadlines  (us):  6536897.00 
Context  Switches  :  576 
Delay  Expirations  :  140 


Cumulative  Execution_Time  (us):  2920436 
Deadlines  Met  :  122 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  636 
Horst  case  blocking  time  in  a  single  period  (us): 

5384 

Cumulative  early  deadlines  (us):  2799953.00 
Context  Switches  :  758 
Delay  Expirations  :  121 


Simulation  Time  (us): 


10000065 


User  Cumulative  Task  Execution  Time  (us) :  8382473 
User  Deadlines  Net  :  1S25 
User  Deadlines  Missed  :  0 
Context  Switches  :  2960 
Delay  Expirations  :  1S20 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  132134 
System  Task  Execution  Time  (us) :  683235 
Idle  Time  (us):  934357 
Percentage  User  Task  Execution  Time  :  83.824185 
Percentage  System  Task  Execution  :  6.832306 
Percentage  Idle  Time  :  9.343509 


C.2.5  Hartstone  Results  -  Experiment  3 


HARTSTOVE  BENCHMARK  SUMMARY  RESULTS 


Baseline  test: 


Experiment:  EXPERIMENT_3  I0IHARM0IIC 

Completion  on:  Miss/skip  50  deadlines 

Raw  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.73 
Test  1  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

No. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  X 

2 

2.30 

16 

36.80 

2.76  X 

3 

4.59 

8 

36.72 

2.75  X 

4 

6.89 

4 

27.56 

2.06  X 

5 

9.19 

2 

18.38 

1.37  X 

183.46 

13.72  X 

Experiment  step  size:  1.87  % 


Test  1  results: 
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Test  duration  (seconds):  10.0 


Task 

Period 

Met 

Missed 

Skipped 

Average 

So. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

434.783 

23 

0 

0 

0.000 

3 

217.865 

46 

0 

0 

0.000 

4 

145.138 

69 

0 

0 

0.000 

5 

108.814 

92 

0 

0 

0.000 

Last  test  with  no  missed/ skipped  deadlines: 


Experiment:  EXPERIMEIT_3  I0VHARM0IIC 

Completion  on:  Miss/skip  50  deadlines 

Ram  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.73 
Test  45  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

76 

152.00 

11.37  X 

2 

2.30 

60 

138.00 

10.32  X 

3 

4.59 

52 

238.68 

17.86  X 

4 

6.89 

48 

330.72 

24.74  X 

5 

9.19 

46 

422.74 

31.62  X 

1282.14  95.92  X 


Experiment  step  size:  1.87  X 


Test  45 

results : 

Test  duration  (seconds) 

:  10.0 

Task 

Period 

Met 

Missed 

Skipped 

Average 

Vo. 

in  msecs  Deadlines 

Deadlines 

Deadlines 

Late  (msec! 

1 

500.000 

20 

0 

0 

0.000 

2 

434.783 

23 

0 

0 

0.000 

3 

217.865 

46 

0 

0 

0.000 

4 

145.138 

69 

0 

0 

0.000 

5 

108.814 

92 

0 

0 

0.000 
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Tost  when  deadlines  first  missed/skipped: 


Experiment :  EXPERIMEHT.3  IOIHARMOHIC 

Completion  on:  Miss/skip  50  deadlines 

Has  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.73 
Test  46  characteristics: 


Task 

Frequency 

Kilo-Vhets 

Kilo-Vhets 

Requested  Vorkload 

Vo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

77 

154.00 

11.52  X 

2 

2.30 

61 

140.30 

10.50  X 

3 

4.69 

53 

243.27 

18.20  X 

4 

6.89 

49 

337.61 

25.26  % 

5 

9.19 

47 

431.93 

32.31  X 

1307.11 

97.78  X 

Experiment  step  size: 

1.87  x 

Test  46 

results : 

Test  duration  (seconds) 

:  10.0 

Task 

Period 

Net 

Missed 

Skipped 

Average 

Vo. 

in  msecs  Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

600.000 

2 

9 

9 

153.293 

2 

434.783 

23 

0 

0 

0.000 

3 

217.866 

46 

0 

0 

0.000 

4 

145.138 

69 

0 

0 

0.000 

5 

108.814 

92 

0 

0 

0.000 

Final  test  performed: 


Experiment:  EXPERIMEIT.3 


Completion  on:  Miss/skip  SO  deadlines 

Raw  speed  in  Kilo-Vhetstone  Instructions  Per  Second  (KVIPS) :  1336.73 
Test  48  characteristics: 


Task 

Frequency 

Kilo-Vhets 

Kilo-Vhets 

Requested  Vorkload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

79 

158 . 00 

11.82  X 

2 

2.30 

63 

144.90 

10.84  X 

3 

4.56 

55 

252.45 

18.89  X 

4 

6.89 

51 

351.39 

26.29  X 

5 

9.19 

49 

450.31 

33.69  X 

1357.05 

101.52  X 

Experiment  step  size:  1.87  X 


Test  48  results: 

Test  duration  (seconds):  10.0 


Task 

Period 

Met 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

2 

9 

9 

197.211 

2 

434.783 

23 

0 

0 

0.000 

3 

217.865 

46 

0 

0 

0.000 

4 

146.138 

69 

0 

0 

0.000 

5 

108.814 

92 

0 

0 

0.000 

Benchmark  :  Hartstone  Benchmark,  Version  1.0 

Compiler  :  System  Designers  ID  Ada  MC68020  Ver  1.0,  Kernel  Ver  V1.2A-33 
Target  :  MVHE133A-20  32-bit  Monoboard  Microcomputer  (68020  9  20.0  MHz) 

Characteristics  of  best  test  for  this  experiment: 

(no  missed/skipped  deadlines) 

Test  45  of  Experiment  3  lonharmonic 

Rav  (non-tasking)  benchmark  speed  in  KVIPS:  1336.73 

Full  task  set: 
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Total  Deadlines  Task  Set  Total 

Tasks  Per  Second  Utilization  KVIPS 

5  24.97  95.92  X  1282.14 

Highest-frequency  task: 

Period  Deadlines  Task  Task 

(■sec)  Per  Second  Utilization  KVIPS 

108.814  9.19  31.62  X  422.74 

Experiment  step  size:  1.87  % 


EID  OF  HARTSTOIE  BE1CHMARK  SUMMARY  RESULTS 


C.2.6  RATESIM  Results  -  Experiment  S 


C.2.6.1  Successful  Scheduling 


I Rate  Monotonic  Scheduler  Model! 


1  -  Add  task  2  -  Remove  task  3  -  Get  from  file 

4  -  Save  to  file  5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

7  -  Edit  task  8  -  Display  tasks  9  -  Quit 

Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  nh_exp3.pas 

Execution 

Task  name  Time(us)  Period(us)/Frequency(Hz)  Deadline(us) 


Task  5 

Rendezvous 

34636 

:  none 

108814 

/ 

9.19 

108814 

Task  4 

Rendezvous 

36132 

:  none 

145138 

/ 

6.89 

145138 

Task  3 

3912S 

217865 

/ 

4.59 

217865 

C-74 


Rendezvous 


:  none 


Task  2 

Rendezvous 

45109 

:  none 

434783 

/ 

2.30 

434783 

Task  1 

Rendezvous 

57079 

:  none 

500000 

/ 

2.00 

500000 

I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 


2  -  Remove  task 
&  -  Perform  simulation 
8  -  Display  tasks 


3  -  Get  from  file 
6  -  Rate  Monotonic  Theorem 
9  -  Quit 


Enter  choice:  p 

Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 

Cumulative  Execution.Time  (us): 

3186512 

Deadlines  Met  : 

92 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

147 

Vorst  case  blocking  time  in  a  single  period  (us): 

Cumulative  early  deadlines  (us) : 

1451 

6764728.00 

Context  Switches  : 

239 

Delay  Expirations  : 

3383333333333833333333333333333333333333 

91 

S3SXSS«S«SSSSSSSS3SS388238SSSSSSSSlS8tZSSSSSSSS3SSSSSSS 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us) :  2493108 
Deadlines  Net  :  69 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  91 
Worst  case  blocking  time  in  a  single  period  (us) : 

1508 

Cumulative  early  deadlines  (us):  5895415.00 
Context  Snitches  :  160 
Delay  Expirations  :  68 


Task  Statistics  for  task  :  Task  3 

Cumulative  Execution.Time  (us):  1799750 
Deadlines  Met  :  46 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  96 
Worst  case  blocking  time  in  a  single  period  (us) : 

2778 

Cumulative  early  deadlines  (us):  3681325.00 
Context  Snitches  :  142 
Delay  Expirations  :  45 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution_Time  (us):  1037507 

Deadlines  Met  :  23 

Deadlines  Missed  :  0 

Preemptions  suffered  due  to  higher  * 

priority  user  tasks  or  system  tasks  :  93 

Worst  case  blocking  time  in  a  single  period  (us): 

6506 

Cumulative  early  deadlines  (us):  1342289.00 

Context  Snitches  :  116 

Delay  Expirations  :  22 
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Task  Statistics  lor  task  :  Task  1 


Cumulative  Execution_Time  (us) :  1141580 
Deadlines  Net  :  20 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  28 
Worst  case  blocking  time  in  a  single  period  (us): 

6517 

Cumulative  early  deadlines  (us):  4647639.00 
Context  Snitches  :  48 
Delay  Expirations  :  19 


Simulation  Time  (us) :  10000102 
User  Cumulative  Task  Execution  Time  (us):  9658457 
User  Deadlines  Met  :  250 
User  Deadlines  Missed  :  0 
Context  Snitches  :  705 
Delay  Expirations  :  245 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  19272 
System  Task  Execution  Time  (us) :  147460 
Idle  Time  (us):  194185 
Percentage  User  Task  Execution  Time  :  96.583585 
Percentage  System  Task  Execution  :  1.474585 
Percentage  Idle  Time  :  1.941830 


C.2.6.2  Scheduling  Failure -  Experiment  S 


(Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Monotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  g 

s3Esssssassss>8sss3sss8s>ss8ssssssssss:::ssas&ssss8=ssssss:sr:srsss3sssssscss3ss 

Enter  file  name  to  get  the  task  set  from:  nh_exp3.fal 
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Task  name 

Execution 
Time (us) 

Per iod (us ) /Frequency (Hz) 

Deadline(us) 

Task  5 

Rendezvous 

34711 

:  none 

108814 

/ 

9.19 

108814 

Task  4 

Rendezvous 

36207 

:  none 

145138 

/ 

6.89 

145138 

Task  3 

Rendezvous 

39200 

:  none 

217865 

/ 

4.59 

217865 

Task  2 

Rendezvous 

45184 

:  none 

434783 

/ 

2.30 

434783 

Task  1 

Rendezvous 

67154 

:  none 

500000 

/ 

2.00 

500000 

I  Rate  Nonotonic  Scheduler  Nodell 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Nonotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 


Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution_Time  (us) :  3193412 
Deadlines  Net  :  92 
Deadlines  Hissed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  148 


Worst  case  blocking  time  in  a  single  period  (us) : 
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Cumulative  early  deadlines  (us) : 
Context  Switches  : 

Delay  Expirations  : 


1414 
674809S . 00 
240 
91 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us) :  2498283 
Deadlines  Met  :  69 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  88 
Worst  case  blocking  time  in  a  single  period  (us) : 

1513 

Cumulative  early  deadlines  (us):  5887428.00 
Context  Switches  :  157 
Delay  Expirations  :  68 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution_Time  (us) :  1803200 
Deadlines  Met  :  46 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  97 
Worst  case  blocking  time  in  a  single  period  (us): 

2809 

Cumulative  early  deadlines  (us);  3594934.00 
Context  Switches  :  143 
Delay  Expirations  :  45 


Task  Statistics  for  task  :  Task  2 


Cumulative  Bxecution_Time  (us): 
Deadlines  Met  : 

Deadlines  Missed  : 
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1039232 

23 

0 


90 


Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

Vorst  case  blocking  time  in  a  single  period  (us): 

6502 

Cumulative  early  deadlines  (us):  1325530.00 

Context  Switches  :  113 

Delay  Expirations  :  22 


Task  Statistics  for  task  :  Task  1 


Cumulative  Execution.Time  (us):  1143080 
Deadlines  Met  :  15 
Deadlines  Missed  :  5 
First  deadline  missed  at  :  1500000 
Execution  completed  at  :  1681646 
Cumulative  late  deadlines  (us):  603912.00 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  38 
Worst  case  blocking  time  in  a  single  period  (us) : 

10833 

Cumulative  early  deadlines  (us):  3349588.00 
Context  Snitches  :  53 
Delay  Expirations  :  14 


Simulation  Time  (us) :  10000032 
User  Cumulative  Task  Execution  Time  (us) :  9677207 
User  Deadlines  Met  :  245 
User  Deadlines  Missed  :  5 
Context  Snitches  :  701 
Delay  Expirations  :  240 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  19561 
System  Task  Execution  Time  (us) :  146069 
Idle  Time  (us):  176736 
Percentage  User  Task  Execution  Time  :  96.771760 
Percentage  System  Task  Execution  :  1.460685 
Percentage  Idle  Time  :  1.767354 


ssssssssssssszsssssssssssssssssssss: 
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C.2.6.S  Scheduling  Failure  -  Experiment  3(Hartstone  Benchmark  Task  Parameters ) 


I  Rate  Monotonic  Scheduler  Nodell 


1  -  Add  task 

4  -  Save  to  file 

7  -  Edit  task 

2  -  Remove  task 

5  -  Perform  simulation 

8  -  Display  tasks 

3  -  Get  from  file 

6  -  Rate  Monotonic  Theorem 
9  -  Quit 

Enter  choice:  g 

Enter  file  name 

Task  name 

to  get 

the  task  set  from:  nh_exp3.fal 
Execution 

Time(us)  Period(us)/Frequency(Ez) 

Deadline (us) 

Task  5 

3S160 

108814  / 

9.19 

108814 

Rendezvous 

none 

Task  4 

36657 

145138  / 

6.89 

145138 

Rendezvous 

none 

Task  3 

39649 

217865  / 

4.59 

217865 

Rendezvous 

none 

Task  2 

45634 

434783  / 

2.30 

434783 

Rendezvous 

: 

none 

Task  1 

57603 

500000  / 

2.00 

500000 

Rendezvous 

: 

none 

I Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Monotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 
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Enter  length  of  simulation  in  microseconds:  10.000.000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution.Time  (us) :  3234720 
Deadlines  Met  :  92 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  144 
Horst  case  blocking  time  in  a  single  period  (us) : 

1504 

Cumulative  early  deadlines  (us):  6708094.00 
Context  Switches  :  236 
Delay  Expirations  :  91 


Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us):  2529333 
Deadlines  Met  :  69 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  86 
Horst  case  blocking  time  in  a  single  period  (us): 

1535 

Cumulative  early  deadlines  (us):  5837444.00 
Context  Switches  :  155 
Delay  Expirations  :  68 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution.Time  (us):  1823854 
Deadlines  Met  :  46 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  110 


Horst  case  blocking  time  in  a  single  period  (us): 
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2742 

Cumulative  early  deadlines  (us) : 

2705467.00 

Context  Snitches  : 

156 

Delay  Expirations  : 

45 

Task  Statistics  for  task  :  Task  2 


Cumulative  Execution.Time  (us) : 

1049582 

Deadlines  Met  : 

23 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

75 

Worst  case  blocking  time  in  a  single  period  (us): 

Cumulative  early  deadlines  (us) : 

6279 

1225310.00 

Context  Snitches  : 

98 

Delay  Expirations  : 

22 

Task  Statistics  for  task  :  Task  1 

Cumulative  Execution_Time  (us) : 

1152060 

Deadlines  Met  : 

4 

Deadlines  Missed  : 

16 

First  deadline  missed  at  : 

500000 

Execution  completed  at  : 

819573 

Cumulative  late  deadlines  (us): 

2686601.00 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

63 

Worst  case  blocking  time  in  a  single  period  (us): 

Cumulative  early  deadlines  (us): 

11433 

131786.00 

Context  Snitches  : 

67 

Delay  Expirations  :  3 


Simulation  Time  (us):  10000073 
User  Cumulative  Task  Execution  Time  (us):  9789549 
User  Deadlines  Net  :  234 
User  Deadlines  Missed  :  16 


083 


Context  Switches  :  696 
Delay  Expirations  :  229 
Rendezvous  executed  :  0 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  17487 
System  Task  Execution  Time  (us) :  143S75 
Idle  Time  (us) :  66885 
Percentage  User  Task  Execution  Time  :  97.894775 
Percentage  System  Task  Execution  :  1.435740 
Percentage  Idle  Time  :  0.668845 


C.S  Task  Set  C  -  Synchronization 

C.S.l  Hartsione  Results  -  Experiment  2  (Task  Set  1) 


HARTSTOVE  BE1CHMARK  SUMMARY  RESULTS 


Baseline  test: 


Experiment:  EXPERIMEIT_2  SYICHR0IIZATI0I  TASK  SET  1 

Completion  on:  Miss/skip  50  deadlines 

Ran  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.75 
Test  1  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo- Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

6.00 

32 

192.00 

14.36  X 

2 

12.00 

16 

192.00 

14.36  X 

3 

24.00 

8 

192.00 

14.36  X 

4 

96.00 

4 

384.00 

28.73  X 

6 

96.00 

2 

192.00 

14.36  X 

1152.00 

86.18  X 

Experiment  step  size:  0.86  X 


Test  1  results: 
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Test  duration  (seconds):  10.0 


Task 

Period 

Net 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

166.667 

60 

0 

0 

0.000 

2 

83.333 

120 

0 

0 

0.000 

3 

41.667 

240 

0 

0 

0.000 

4 

10.417 

960 

0 

0 

0.000 

5 

10.417 

960 

0 

0 

0.000 

Last  test  with  no  missed/ skipped  deadlines: 


Experiment:  EXPERIMEIT_2  SYICHR0IIZATI0I  TASK  SET  1 

Completion  on:  Miss/skip  SO  deadlines 

Rau  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS):  1336.75 
Test  6  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

6.30 

32 

201.60 

15.08  X 

2 

12.60 

16 

201.60 

15.08  X 

3 

25.20 

8 

201.60 

15.08  % 

4 

100.80 

4 

403.20 

30.16  X 

S 

100.80 

2 

201.60 

15.08  X 

1209.60 

90.49  X 

Experiment  step  size:  0.86  % 


Test  6  results: 

Test  duration  (seconds):  10.0 


Task 

Period 

Met 

Missed 

Skipped 

Average 

fo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

168.730 

64 

0 

0 

0.000 

2 

79.365 

127 

0 

0 

0.000 

3 

39.683 

253 

0 

0 

0.000 

4 

9.921 

1009 

0 

0 

0.000 

5 

9.921 

1009 

0 

0 

0.000 

Test  when  deadlines  first  missed/skipped: 


Experiment:  EXPERIMEIT_2  SYICHROVIZATIOf  TASK  SET  1 

Completion  on:  Miss/skip  50  deadlines 

Ran  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KVIPS) :  1336.75 
Test  7  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

lo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

6.36 

32 

203.52 

15.22  y. 

2 

12.72 

16 

203.52 

15.22  % 

3 

25.44 

8 

203 . 52 

15.22  X 

4 

101.76 

4 

407.04 

30.45  X 

5 

101.76 

2 

203.52 

15.22  X 

1221.12 

91.35  y. 

Experiment  step  size:  0.86  X 


Test  7  results: 

Test  duration  (seconds):  10.0 


Task 

Period 

Net 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

157.233 

0 

32 

32 

55.014 

2 

78.616 

128 

0 

0 

0.000 

3 

39.308 

255 

0 

0 

0.000 

4 

9.827 

1018 

0 

0 

0.000 

5 

9.827 

1018 

0 

0 

0.000 

Final  test  performed: 

See  preceding  summary  of  test  7 


Benchmark  :  Hart stone  Benchmark,  Version  1.0 
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Compiler  :  System  Designers  XD  Ada  MC68020  Ver  1.0,  Kernel  Ver  V1.2A-33 
Target  :  MVME133A-20  32-bit  Monoboard  Microcomputer  (68020  €  20.0  MHz) 

Characteristics  of  best  test  for  this  experiment: 

(no  missed/skipped  deadlines) 

Test  6  of  Experiment  2  Synchronization  Task  Set  1 

Ram  (non-tasking)  benchmark  speed  in  KVIPS:  1336.75 

Full  task  set: 

Total  Deadlines  Task  Set  Total 

Tasks  Per  Second  Utilization  KVIPS 

5  245.70  90.49  %  1209.60 

Highest-! requency  task : 

Period  Deadlines  Task  Task 

(msec)  Per  Second  Utilization  KVIPS 

9.921  100.80  15.08  X  201.60 

Experiment  step  size:  0.86  % 


EID  OF  HARTST01E  BEICHMARK  SUMMARY  RESULTS 

C.S.S  RATESIM  Results  -  Experiment  2  (Task  Set  1) 

C.S.2.1  Synchronization  Successful  Scheduling 


I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task  2  -  Remove  task  3  -  Get  from  file 

4  -  Save  to  file  5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

7  -  Edit  task  8  -  Display  tasks  9  -  quit 

Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  syncl.pass 

Execution 

Task  name  Time(us)  Period(us) /Frequency (Hz)  Deadline(us) 
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Task  4 

Rendezvous  : 

Start 

Length 

2992 

Type 

10417  / 

lame 

96.00 

10417 

0 

0 

AIACCEPT 

a 

Task  5 

Rendezvous  : 

Start 

Length 

1496 

Type 

10417  / 

lame 

96.00 

10417 

0 

0 

A.CALL 

a 

Task  3 

Rendezvous 

S984 

:  none 

41667  / 

24.00 

41667 

Task  2 

Rendezvous 

11969 

:  none 

83333  / 

12.00 

83333 

Task  1 

Rendezvous 

23938 

:  none 

166667  / 

6.00 

166667 

I  Rats  Monotonic  Scheduler  Model I 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  p 


2  -  Remove  task 
5  -  Perform  simulation 
8  -  Display  tasks 


3  -  Get  from  file 
6  -  Rate  Monotonic  Theorem 
9  -  Quit 


Enter  length  of  simulation  in  microseconds:  10.000.000 
Print  the  Event  History  (y  or  n)  :  n 


SSSBSSSSSSSS3SSZSSS3SS8SX3SSSSSSSS8SSSSSSSSSSSS3SSSSSSS 


Task  Statistics  for  task  :  Task  4 
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Cumulative  Execution.Time  (us) :  2872320 
Deadlines  Net  :  960 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1060 
Worst  case  blocking  time  in  a  single  period  (us) : 

1012 

Cumulative  early  deadlines  (us):  6372124.00 
Context  Switches  :  2980 
Delay  Expirations  :  ggg 


Task  Statistics  for  task  :  Task  5 

Cumulative  Execution.Time  (us): 

1436160 

Deadlines  Net  : 

960 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

1000 

Worst  case  blocking  time  in  a  single  period  (us) : 

Cumulative  early  deadlines  (us) : 

934 

4786364.00 

Context  Switches  : 

1960 

Delay  Expirations  : 

959 

Task  Statistics  for  task  :  Task  3 


Cumulative  Execution_Time  (us) :  1436160 
Deadlines  Net  :  240 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  307 
Worst  case  blocking  time  in  a  single  period  (us) : 

2510 

Cumulative  early  deadlines  (us):  5880079.00 
Context  Snitches  :  547 
Delay  Expirations  :  239 


Task  Statistics  f or  task  :  Task  2 


Cumulative  Execution_Time  (us): 

1436280 

Deadlines  Net  : 

120 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

317 

Worst  case  blocking  time  in  a  single  period  (us): 

5104 

Cumulative  early  deadlines  (us): 

5133282.00 

Context  Switches  : 

437 

Delay  Expirations  : 

119 

Task  Statistics  for  task  :  Task  1 

Cumulative  Execution_Time  (us) : 

1436280 

Deadlines  Met  : 

60 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

452 

Worst  case  blocking  time  in  a  single  period  (us): 

19093 

Cumulative  early  deadlines  (us): 

470352.00 

Context  Switches  : 

512 

Delay  Expirations  : 

59 

Simulation  Time  (us) : 

10000015 

User  Cumulative  Task  Execution  Time  (us) : 

8617200 

User  Deadlines  Met  : 

2340 

User  Deadlines  Missed  : 

0 

Context  Switches  : 

5479 

Delay  Expirations  : 

2335 

Rendezvous  executed  : 

960 

Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us): 

173643 

System  Task  Execution  Time  (us) : 

1095856 

Idle  Time  (us): 

286959 

Percentage  User  Task  Execution  Time  : 

86.171871 

Percentage  System  Task  Execution  : 

10.958544 

Percentage  Idle  Time  : 

2.869586 
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C.3.2.2  Synchronization  Scheduling  Failure  -  Experiment  2  ( Task  Set  1) 


I  Rate  Monotonic  Scheduler  Model | 


1  -  Add  task 

4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  g 

2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 

Enter  file  name 

to  get  the  task  set 
Execution 

from:  syncl.fail 

Task  name 

Time (us) 

Period(us) /Frequency (Hz)  Deadline(us) 

Task  4 

Rendezvous  : 

2992 

9921  /  100.80  9921 

Start 

Length  Type 

lame 

-  - 

- - 

0 

0  AIACCEPT 

a 

Task  5 

Rendezvous  : 
Start 

Length 

1496 

Type 

9921 

lame 

/ 

100.80 

9921 

0 

0 

A.CALL 

a 

Task  3 

Rendezvous 

5984 

:  none 

39683 

/ 

25.20 

39683 

Task  2 

Rendezvous 

11969 

:  none 

79365 

/ 

12.60 

79365 

Task  1 

Rendezvous 

23938 

:  none 

158730 

/ 

6.30 

158730 

SSSSSSSSSS388SS8S8SS3SSSSSSSS 


I  Rate  Monotonic  Scheduler  Model I 
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1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 


2  -  Remove  task 
S  -  Perform  simulation 
8  -  Display  tasks 


3  -  Get  from  file 
6  -  Rate  Monotonic  Theorem 
9  -  Quit 


Task  Statistics  for  task  :  Task  5 

Cumulative  Execution_Time  (us) :  1507968 

Deadlines  Met  :  1008 

Deadlines  Missed  :  0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1051 

Horst  case  blocking  time  in  a  single  period  (us): 

933 

Cumulative  early  deadlines  (us):  4524316.00 

Context  Switches  :  2059 

Delay  Expirations  :  1007 


Cumulative  Execution.Time  (us) :  1507968 
Deadlines  Met  :  252 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  388 
Worst  case  blocking  time  in  a  single  period  (us): 

2622 

Cumulative  early  deadlines  (us):  5662068.00 
Context  Switches  :  640 
Delay  Expirations  :  251 


Cumulative  Execution_Time  (us) :  1508094 
Deadlines  Met  :  126 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  416 
Worst  case  blocking  time  in  a  single  period  (us): 

7616 

Cumulative  early  deadlines  (us):  2718723.00 
Context  Switches  :  542 
Delay  Expirations  :  125 


Task  Statistics  for  task  :  Task  1 


Cumulative  ExecutionJFime  (us) :  1310681 
Deadlines  Met  :  0 
Deadlines  Missed  :  54 
First  deadline  missed  at  :  158730 
Execution  completed  at  :  224525 
Cumulative  late  deadlines  (us):  34108980.00 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  466 
Worst  case  blocking  time  in  a  single  period  (us) : 

27396 

Cumulative  early  deadlines  (us):  0.00 
Context  Switches  :  466 
Delay  Expirations  :  0 
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Simulation  Time  (us): 

10000100 

User  Cumulative  Task  Execution  Time  (us) : 

8850647 

User  Deadlines  Met  : 

2394 

User  Deadlines  Missed  : 

54 

Context  Switches  : 

6771 

Delay  Expirations  : 

2390 

Rendezvous  executed  : 

1008 

Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us): 

182082 

System  Task  Execution  Time  (us) : 

1149237 

Idle  Time  (us) : 

0 

Percentage  User  Task  Execution  Time  : 

88.505585 

Percentage  System  Task  Execution  : 

11.492255 

Percentage  Idle  Time  : 

0.000000 

C.S.2.S  Scheduling  Failure  -  Task  Set  lfHartstone  Benchmark  Task  Parameters) 


I Rate  Monotonic  Scheduler  Model I 


1  -  Add  task  2  -  Remove  task  3  -  Get  from  file 

4  -  Save  to  file  5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

7  -  Edit  task  8  -  Display  tasks  9  -  Quit 

Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  sync l_hart. fail 

Execution 

Task  name  Time(us)  Period(us) /Frequency (Hz)  Deadline (us) 


Task  E  1496  9827  /  101.76  9827 

Rendezvous  : 

Start  Length  Type  lame 


0  0  A_CALL  a 


Task  4  2992  9827  /  101.76  9827 

Rendezvous  : 

Start  Length  Type  lame 
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0 


0 


AIACCEPT 


a 


Task  3 

Rendezvous 

5984 

:  none 

39308 

/ 

25.44 

39308 

Task  2 

Rendezvous 

11969 

:  none 

78616 

/ 

12.72 

78616 

Task  1 

Rendezvous 

23938 

:  none 

157233 

/ 

6.36 

157233 

I  Rate  Nonotonic  Scheduler  Model I 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

6  -  Perform  simulation 

6  -  Rate  Nonotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 


Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  5 


Cumulative  Execution.Time  (us):  1522928 
Deadlines  Net  :  1018 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1065 
Worst  case  blocking  time  in  a  single  period  (us): 

955 

Cumulative  early  deadlines  (us):  4460447.00 
Context  Switches  :  2083 
Delay  Expirations  :  1017 


Task  Statistics  lor  task  :  Task  4 

Cumulative  Execution.Time  (us): 

3045856 

Deadlines  Net  : 

1018 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

1104 

Worst  case  blocking  time  in  a  single  period  (us) : 

879 

Cumulative  early  deadlines  (us) : 

6141945.00 

Context  Snitches  : 

3140 

Delay  Expirations  : 

1017 

Task  Statistics  for  task  :  Task  3 

Cumulative  Execution_Time  (us): 

1525920 

Deadlines  Net  : 

255 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

294 

Worst  case  blocking  time  in  a  single  period  (us): 

2325 

Cumulative  early  deadlines  (us) : 

5664070.00 

Context  Snitches  : 

549 

Delay  Expirations  : 

254 

Task  Statistics  for  task  :  Task  2 


Cumulative  Execution.Time  (us): 

1522692 

Deadlines  Net  : 

127 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

419 

Worst  case  blocking  time  in  a  single  period  (us) : 

Cumulative  early  deadlines  (us): 

6891 

2681980.00 

Context  Snitches  : 

546 
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Delay  Expirations  : 


127 


Task  Statistics  lor  task  :  Task  1 


Cumulative  Execution_Time  (us):  1259118 
Deadlines  Met  :  0 
Deadlines  Missed  :  52 
First  deadline  missed  at  :  157233 
Execution  completed  at  :  224525 
Cumulative  late  deadlines  (us):  46335528.00 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  465 
Horst  case  blocking  time  in  a  single  period  (us): 

26016 

Cumulative  early  deadlines  (us):  0.00 
Context  Switches  :  465 
Delay  Expirations  :  0 


Simulation  Time  (us):  10004000 
User  Cumulative  Task  Execution  Time  (us):  8876514 
User  Deadlines  Met  :  2418 
User  Deadlines  Missed  :  52 
Context  Switches  :  5715 
Delay  Expirations  :  2415 
Rendezvous  executed  :  1018 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  228590 
System  Task  Execution  Time  (us):  1127278 
Idle  Time  (us):  0 
Percentage  User  Task  Execution  Time  :  88.729648 
Percentage  System  Task  Execution  :  11.268273 
Percentage  Idle  Time  :  0.000000 


C.S.S  Hartstone  Results  -  Experiment  2  ( Task  Set  2) 


HARTST0IE  BEICHMARK  SUMMARY  RESULTS 
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Baseline  test: 


Experiment 

EXPERIMEXT.2  SYICHROIIZATIOI  TASK  SET  2 

Completion 

on:  Hiss/skip  50  deadlines 

Ram  speed  in  Kilo-Vhetstone  Instructions  Per  Second  (KVIPS):  1336.73 

Test  1  characteristics: 

Task  Frequency 

Kilo-Vhets 

Kilo-Vhets 

Requested  Vorkload 

Vo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

2.00 

32 

64.00 

4.79  X 

2 

4.00 

16 

64.00 

4.79  X 

3 

8.00 

8 

64.00 

4.79  X 

4 

32.00 

4 

128.00 

9.58  X 

5 

32.00 

0 

0.00 

0.00  X 

320.00 

23.94  X 

Experiment 

step  size: 

2.39  y. 

Test  1  results: 

Test  duration  (seconds) 

Task  Period 

:  10.0 

Net 

Missed 

Skipped 

Average 

■o. 

in  msecs  Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

500.000 

20 

0 

0 

0.000 

2 

250.000 

40 

0 

0 

0.000 

3 

125.000 

80 

0 

0 

0.000 

4 

31.250 

320 

0 

0 

0.000 

5 

31.260 

320 

0 

0 

0.000 

Last  test  with  no  missed/ skipped  deadlines: 

SSS3S2SS8S8SS8SSSSS53S8SSSSSS8SS3SSSS8SISS8SSrSSSSSSSS3SSS:SSSStSS8SSSrs 

Experiment:  EXPERIHEIT_2  SYICHROIIZATIOI  TASK  SET  2 

Completion  on:  Niss/skip  50  deadlines 

Ram  speed  in  Kilo-Vhetstone  Instructions  Per  Second  (KVIPS):  1336.73 
Test  28  characteristics: 
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Task  Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

Vo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

7.40 

32 

236 . 80 

17.71  X 

2 

14.80 

16 

236.80 

17.71  X 

3 

29.60 

8 

236.80 

17.71  y. 

4 

118.40 

4 

473.60 

35.43  X 

5 

118.40 

0 

0.00 

0.00  y. 

1184.00 

88.57  X 

Experiment 

step  size: 

2.39  y. 

Test  28 

results : 

Test  duration  (seconds):  10.0 

Task 

Period 

Met 

Missed 

Skipped 

Average 

Vo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

135.135 

75 

0 

0 

0.000 

2 

67.568 

149 

0 

0 

0.000 

3 

33.784 

297 

0 

0 

0.000 

4 

8.446 

1185 

0 

0 

0.000 

5 

8.446 

1185 

0 

0 

0.000 

Test  when  deadlines  first  missed/ skipped: 


Experiment:  EXPERIKEIT_2  SYICHROIIZATIOV  TASK  SET  2 

Completion  on:  Niss/skip  50  deadlines 

Raw  speed  in  Kilo-Whetstone  Instructions  Per  Second  (KWIPS):  1336.73 
Test  29  characteristics: 


Task 

Frequency 

Kilo-Whets 

Kilo-Whets 

Requested  Workload 

Vo. 

(Hertz) 

per  period 

per  second 

Utilization 

1 

7.60 

32 

243.20 

18.19  X 

2 

15.20 

16 

243.20 

18.19  X 

3 

30.40 

8 

243 . 20 

18.19  X 

4 

121.60 

4 

486.40 

36.39  X 

5 

121.60 

0 

0.00 

0.00  X 

1216.00 

90.97  X 
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Experiment  step  size:  2.39  X 


Test  29  results: 

Test  duration  (seconds):  10.0 


Task 

Period 

Met 

Missed 

Skipped 

Average 

lo. 

in  msecs 

Deadlines 

Deadlines 

Deadlines 

Late  (msec) 

1 

131.679 

0 

38 

38 

63.666 

2 

66.789 

162 

0 

0 

0.000 

3 

32.896 

304 

0 

0 

0.000 

4 

8.224 

1216 

0 

0 

0.000 

6 

8.224 

1216 

0 

0 

0.000 

Final  test  performed: 

See  preceding  summary  of  test  29 


Benchmark  :  Hartstone  Benchmark,  Version  1.0 

Compiler  :  System  Designers  ZD  Ada  MC68020  Ver  1.0,  Kernel  Ver  V1.2A-33 
Target  :  MVME133A-20  32-bit  Monoboard  Microcomputer  (68020  •  20.0  MHz) 

Characteristics  of  best  test  for  this  experiment: 

(no  missed/skipped  deadlines) 

Test  28  of  Experiment  2  Synchronization  Task  Set  2 

Raw  (non-tasking)  benchmark  speed  in  KVIPS:  1336.73 

Full  task  set: 


Total  Deadlines 

Tasks  Per  Second 

5  288.60 


Task  Set  Total 

Utilization  KVIPS 

88.67  X  1184.00 


Highest-frequency  task: 


Period 

(■■•c) 

8.446 


Deadlines  Task 

Per  Second  Utilization 

118.40  0.00  X 


Task 

KVIPS 

0.00 
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Experiment  step  size:  2.39  '/, 


ESD  OF  HARTSTOHE  BEICHMARK  SUMMARY  RESULTS 


C.3.4  RATESIM  Results  -  Experiment  2  (Task  Set  2) 


C.S.j.l  Synchronization  Successful  Scheduling  -  Experiment  2  (Task  Set  2) 


I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 

4  -  Save  to  file 
7  -  Edit  task 

Enter  choice:  g 

2  -  Remove  task 

6  -  Perform  simulation 
8  -  Display  tasks 

3  -  Get  from  file 

6  -  Rate  Monotonic  Theorem 
9  -  Quit 

Enter  Tile  name 

to  get  the  task  set 

from:  sync2_pass 

Execution 

Task  name 

Time (us) 

Period(us) /Frequency (Hz)  Deadline(us) 

Task  4 

2992 

8717  / 

114.72  8717 

Rendezvous  : 

Start 

Length  Type 

lame 

0 

1496  AIACCEPT 

a 

Task  5 

Rendezvous  : 

Start 

1 

Length  Type 

8717 

lame 

/ 

114.72 

8717 

0 

0  A.CALL 

a 

Task  3 

S984 

34868 

/ 

28.68 

34868 
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Rendezvous 


:  none 


Task  2 

Rendezvous 

11969 

:  none 

69735 

/ 

14.34 

69735 

Task  1 

Rendezvous 

23938 

:  none 

139470 

/ 

7.17 

139470 

I  Rate  Monotonic  Scheduler  Model I 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Monotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 

Enter  length  of  simulation  in  microseconds:  10_ 000_000 
Print  the  Event  History  (y  or  n)  :  n 


Task  Statistics  for  task  :  Task  4 

Cumulative  Execut ion_Time  (us): 

3434816 

Deadlines  Met  : 

1148 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

1248 

Worst  case  blocking  time  in  a  single  period  (us): 

1152 

Cumulative  early  deadlines  (us): 

5637780.00 

Context  Switches  : 

3544 

Delay  Expirations  : 

1147 

Task  Statistics  for  task  :  Task  5 
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Cumulative  Execution.Time  (us):  1148 
Deadlines  Net  :  1148 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1253 
Worst  case  blocking  time  in  a  single  period  (us): 

912 

Cumulative  early  deadlines  (us):  5465088.00 
Context  Snitches  :  2401 
Delay  Expirations  :  1147 


Task  Statistics  for  task  :  Task  3 


Cumulative  Execution.Time  (us) :  1717408 
Deadlines  Net  :  287 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  335 
Worst  case  blocking  time  in  a  single  period  (us) : 

2390 

Cumulative  early  deadlines  (us):  5941042.00 
Context  Snitches  :  622 
Delay  Expirations  :  286 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution_Time  (us):  1723536 
Deadlines  Net  :  144 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  348 
Worst  case  blocking  time  in  a  single  period  (us): 

5028 

Cumulative  early  deadlines  (us):  5076117.00 
Context  Snitches  :  492 
Delay  Expirations  :  143 
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Task  Statistics  lor  task  :  Task  1 


Cumulative  Execution_Time  (us):  1713056 
Deadlines  Net  :  71 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  550 
Worst  case  blocking  time  in  a  single  period  (us): 

18999 

Cumulative  early  deadlines  (us):  111951.00 
Context  Snitches  :  621 
Delay  Expirations  :  71 


Simulation  Time  (us):  10007179 
User  Cumulative  Task  Execution  Time  (us) :  8589964 
User  Deadlines  Met  :  2798 
User  Deadlines  Missed  :  0 
Context  Switches  :  6532 
Delay  Expirations  :  2794 
Rendezvous  executed  :  1148 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  237238 
System  Task  Execution  Time  (us) :  1302097 
Idle  Time  (us):  115118 
Percentage  User  Task  Execution  Time  :  85.838017 
Percentage  System  Task  Execution  :  13.011629 
Percentage  Idle  Time  :  1.150354 


C.8.4-2  Synchronization  Scheduling  Failure  -  Experiment  2  (Task  Set  2) 


I  Rate  Monotonic  Scheduler  Model! 


1  -  Add  task 
4  -  Save  to  file 
7  -  Edit  task 


2  -  Remove  task  3  -  Get  from  file 

5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

8  -  Display  tasks  9  -  Quit 


Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  sync2_fail 
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Task  name 


Execution 

Time(us)  Period (us) /Frequency (Hz)  Deadline(us) 


Task  4 

Rendezvous  : 

Start 

Length 

2992 

Type 

8705 

lame 

/ 

114.88 

8705 

0 

1496 

AIACCEPT 

a 

Task  5 

Rendezvous  : 

Start 

Length 

1 

Type 

8705 

lame 

/ 

114.88 

8705 

0 

0 

A.CALL 

a 

Task  3 

Rendezvous 

5984 

:  none 

34819 

/ 

28.72 

34819 

Task  2 

Rendezvous 

11969 

:  none 

69638 

/ 

14.36 

69638 

Task  1 

Rendezvous 

23938 

:  none 

13*276 

/ 

7.18 

139276 

I  Rate  Honotonic  Scheduler  Nodell 


1  -  Add  task 

2  -  Remove  task 

3  -  Get  from  file 

4  -  Save  to  file 

5  -  Perform  simulation 

6  -  Rate  Nonotonic  Theorem 

7  -  Edit  task 

8  -  Display  tasks 

9  -  Quit 

Enter  choice:  p 

Enter  length  of  simulation  in  microseconds:  10_000_000 
Print  the  Event  History  (y  or  n)  :  n 
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Task  Statistics  for  task  :  Task  4 


Cumulative  Execution_Time  (us) : 

3437808 

Deadlines  Net  : 

1149 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

1259 

Worst  case  blocking  time  in  a  single  period  (us) : 

1051 

Cumulative  early  deadlines  (us) : 

5629713.00 

Context  Switches  : 

3557 

Delay  Expirations  : 

1148 

Task  Statistics  for  task  :  Task  5 

Cumulative  ExecutionJFime  (us): 

1149 

Deadlines  Met  : 

1149 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

1275 

Horst  case  blocking  time  in  a  single  period  (us) : 

934 

Cumulative  early  deadlines  (us) : 

5456871.00 

Context  Switches  : 

2424 

Delay  Expirations  : 

1148 

Task  Statistics  for  task  :  Task  3 


Cumulative  Execution_Time  (us):  1721972 
Deadlines  Net  :  287 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  421 
Horst  case  blocking  time  in  a  single  period  (us) : 

2819 

Cumulative  early  deadlines  (us):  5896343.00 
Context  Switches  :  708 
Delay  Expirations  :  287 
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Task  Statistics  lor  task  :  Task  2 


Cumulative  Execution.Time  (us) : 

1723536 

Deadlines  Met  : 

144 

Deadlines  Missed  : 

0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  : 

341 

Worst  case  blocking  time  in  a  single  period  (us): 

Cumulative  early  deadlines  (us) : 

7522 

4878305.00 

Context  Switches  : 

485 

Delay  Expirations  : 

143 

Task  Statistics  for  task  :  Task  1 

Cumulative  Execution_Time  (us): 

1712001 

Deadlines  Met  : 

69 

Deadlines  Missed  : 

2 

First  deadline  missed  at  : 

8078008 

Execution  completed  at  : 

8078013 

Cumulative  late  deadlines  (us): 

Preemptions  suffered  due  to  higher 

49502.00 

priority  user  tasks  or  system  tasks  : 

537 

Worst  case  blocking  time  in  a  single  period  (us) : 

27126 

Cumulative  early  deadlines  (us) : 

70667.00 

Context  Switches  : 

606 

Delay  Expirations  : 

69 

Simulation  Time  (us):  10002048 
User  Cumulative  Task  Execution  Time  (us):  8596466 
User  Deadlines  Met  :  2798 
User  Deadlines  Missed  :  2 
Context  Switches  :  6629 
Delay  Expirations  :  2795 
Rendezvous  executed  :  1149 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  237328 
System  Task  Execution  Time  (us) :  1331845 
Idle  Time  (us):  73729 
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Percentage  User  Task  Execution  Time  : 
Percentage  System  Task  Execution  : 
Percentage  Idle  Time  : 


85 . 947058 
13.315723 
0.737139 


C.S.4-S  Scheduling  Failure  -  Task  Set  2(Hartstone  Benchmark  Task  Parameters) 


I  Rate  Nonotonic  Scheduler  Hodell 


1  -  Add  task  2  -  Remove  task  3  -  Get  from  Tile 

4  -  Save  to  file  5  -  Perform  simulation  6  -  Rate  Monotonic  Theorem 

7  -  Edit  task  8  -  Display  tasks  9  -  quit 

Enter  choice:  g 


Enter  file  name  to  get  the  task  set  from:  sync2_hart.fail 

Execution 

Task  name  Time(us)  Period(us)/Frequency(Ez)  Deadline(us) 

Task  5  1  8224  /  121.60  8224 

Rendezvous  : 

Start  Length  Type  Name 


0  0  A.CALL  a 


Task  3 

Rendezvous 

5984 

:  none 

32895 

/ 

30.40 

32895 

Task  2 

Rendezvous 

11969 

:  none 

65789 

/ 

15.20 

65789 

Task  1 

23938 

131579 

/ 

7.60 

131579 

C-108 


Rendezvous 


:  none 


Task  Statistics  lor  task  :  Task  4 


Cumulative  Execution_Time  (us):  3638272 

Deadlines  Net  :  1216 

Deadlines  Missed  :  0 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  1330 

Horst  case  blocking  time  in  a  single  period  (us) : 

1040 

Cumulative  early  deadlines  (us):  5374430.00 
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Context  Snitches  : 
Delay  Expirations  : 


3762 

1215 


Task  Statistics  lor  task  :  Task  3 


Cumulative  Execution.Time  (us) :  1819136 
Deadlines  Met  :  304 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  480 
Worst  case  blocking  time  in  a  single  period  (us): 

2855 

Cumulative  early  deadlines  (us):  5650640.00 
Context  Snitches  :  784 
Delay  Expirations  :  303 


Task  Statistics  for  task  :  Task  2 


Cumulative  Execution.Time  (us) :  1819288 
Deadlines  Met  :  152 
Deadlines  Missed  :  0 
Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  534 
Worst  case  blocking  time  in  a  single  period  (us) : 

8965 

Cumulative  early  deadlines  (us):  2538453.00 
Context  Snitches  :  686 
Delay  Expirations  :  151 


Task  Statistics  for  task  :  Task  1 


Cumulative  Execution_Time  (us):  1311486 
Deadlines  Met  :  0 
Deadlines  Missed  :  64 
First  deadline  missed  at  :  131579 
Execution  completed  at  :  194282 
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Cumulative  late  deadlines  (us):  71648499.00 

Preemptions  suffered  due  to  higher 

priority  user  tasks  or  system  tasks  :  539 

Worst  case  blocking  time  in  a  single  period  (us) : 

29457 

Cumulative  early  deadlines  (us):  0.00 

Context  Switches  :  539 

Delay  Expirations  :  0 


Simulation  Time  (us) :  10000040 
User  Cumulative  Task  Execution  Time  (us):  8589398 
User  Deadlines  Met  :  2888 
User  Deadlines  Missed  :  54 
Context  Switches  :  7016 
Delay  Expirations  :  2884 
Rendezvous  executed  :  1216 
Cumulative  induced  priority  inversion 

time  due  to  DELAY  statement  jitter  (us):  250963 
System  Task  Execution  Time  (us) :  1410426 
Idle  Time  (us) :  0 
Percentage  User  Task  Execution  Time  :  85.893636 
Percentage  System  Task  Execution  :  14.104204 
Percentage  Idle  Time  :  0.000000 
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Appendix  D.  R AT ESIM  Source  Code 


This  appendix  is  available  upon  request,  direct  requests  to: 

Major  Paul  Bailor 

Department  of  the  Air  Force 

AFIT/ENG  WPAFB,  OH  45433-7765 

email:  pbailor@afit.af.mil 

comm:  (513)255-3708 

DSN:  785-3708 

or 

Captain  Rusty  Baldwin 
210  Blair  Drive 
Fairborn,  OH  45324. 
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Appendix  E.  ACEC  Test  Results 


This  appendix  is  available  upon  request,  direct  requests  to: 

Major  Paul  Bailor 

Department  of  the  Air  Force 

AFIT/ENG  WPAFB,  OH  45433-7765 

email:  pbailor@afit .af.mil 

comm:  (513)255-3708 

DSN:  785-3708 

or 

Captain  Rusty  Baldwin 
210  Blair  Drive 
Fairborn,  OH  45324. 
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Appendix  F.  RATESIM  User’s  Manual 


This  appendix  is  available  upon  request,  direct  requests  to: 

Major  Paul  Bailor 

Department  of  the  Air  Force 

AFIT/ENG  WPAFB,  OH  45433-7765 

email:  pbailor@aht.af.mil 

comm:  (513)255-3708 

DSN:  785-3708 

or 

Captain  Rusty  Baldwin 
210  Blair  Drive 
Fairborn,  OH  45324. 
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